Azure PaaS サービスを使うスポークバーチャルネットワークにゼロトラスト原則を適用する

[アーティクル]
04/17/2024

この記事では、次の方法で Azure バーチャルネットワーク (VNet) とプライベートエンドポイントを使用して、ゼロトラストセキュリティモデルの原則を PaaS ワークロードに適用するのに役立ちます。

ゼロトラストの標準	定義	以下により適合
明示的に検証する	常に利用可能なすべてのデータポイントに基づいて認証および承認してください。	Azureファイヤウォールと Azure アプリlication Gateway の脅威検出を使用して、トラフィックを検証し、トラフィックが許容できるかどうかを確認します。
最小限の特権アクセスを使用する	ジャスト・イン・タイムおよびジャスト・エナフ・アクセス（JIT/JEA）、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。	Azure サービスからプライベートネットワークへのイングレスとエグレスを減らします。ネットワークセキュリティグループを使用して、VNet からの特定のイングレスのみを許可します。中央の Azureファイヤウォールインスタンスを使用して、VNet 以外のトラフィックに Azure サービスへのアクセスを許可します。
侵害を前提とする	影響範囲を最小限に抑えるために、アクセスをセグメント化します。エンドツーエンドの暗号化を検証し、分析を使用して可視性を得て、脅威検出を促進し、防御を強化します。	リソース間の不要な通信を制限します。ネットワークセキュリティグループからのログを記録していること、および異常なトラフィックを適切に可視化していることを確認します。ネットワークセキュリティグループの変更を追跡します。

Azure IaaS 環境全体でゼロトラストの原則を適用する方法の詳細については、「Azure IaaS にゼロトラスト原則を適用する」の概要を参照してください。

Azure PaaS サービス用のゼロトラストスタンドアロンまたはスポークネットワーク

多くの PaaS サービスには、独自のサービスネイティブのイングレスおよびエグレス制御機能が含まれています。これらの制御を使用すると、VNet などのインフラストラクチャを必要とせずに、PaaS サービスリソースへのネットワークアクセスをセキュリティで保護できます。次に例を示します。

Azure SQL Database には、データベースサーバーにアクセスする必要がある特定のクライアント IP アドレスを許可するために使用できる独自のファイアウォールがあります。
Azure ストレージアカウントには、特定の VNet からの接続を許可するか、パブリックネットワークアクセスをブロックするための構成オプションがあります。
Azure アプリ Service は、アプリへのネットワークアクセスを制御する優先順位の許可/拒否リストを定義するアクセス制限をサポートしています。

ただし、ゼロトラストガイド付き実装の場合、これらのサービスネイティブアクセス制御では十分ではありません。これにより、アクセス制御とログ記録の拡散が生じ、管理が向上し、可視性が低下する可能性があります。

さらに、PaaS サービスでは、サービスの種類に対して特定のリージョンのパブリック IP アドレスのプールから割り当てられた動的に割り当てられたパブリック IP アドレスに解決される完全修飾ドメイン名 (FQDN) を使用できます。このため、パブリック IP アドレスを使用して特定の PaaS サービスからのトラフィックや特定の PaaS サービスへのトラフィックを許可することはできません。これは変更される可能性があります。

Microsoftでは、プライベートエンドポイントの使用をお勧めしています。プライベートエンドポイントは、VNet のプライベート IP アドレスを使用する VNet インターフェイスです。ユーザーはこのネットワークインターフェイスにより、Azure Private Link を利用するサービスに非公開で安全に接続します。プライベートエンドポイントを有効にすると、サービスが VNet に導入されます。

ソリューションのシナリオによっては、PaaS サービスへのパブリック受信アクセスが引き続き必要になる場合があります。ただし、お客様が行わない限り、潜在的なセキュリティリスクを排除するために、すべてのトラフィックメインプライベートにすることをお勧めします。

このガイドでは、特定の参照アーキテクチャの手順を説明しますが、原則と方法は必要に応じて他のアーキテクチャに適用できます。

参照アーキテクチャ

次の図は、PaaS ベースのワークロードの一般的な参照アーキテクチャを示しています。

図の説明：

スポーク VNet には、PaaS アプリケーションをサポートするコンポーネントが含まれています。
PaaS アプリケーションは、Web アプリ/フロントエンド用の Azure アプリlication Services とリレーショナルデータベース用の Azure SQL Database を利用する 2 層アプリケーションです。
各層は、専用のネットワークセキュリティグループを使用したイングレス用の専用サブネット内に含まれています。
Web 層には、エグレス用の専用サブネットが含まれています。
アプリケーションへのアクセスは、独自のサブネットに含まれるアプリケーションゲートウェイを介して提供されます。

次の図は、Azure サブスクリプション内のこれらのコンポーネントの論理アーキテクチャを示しています。

この図では、スポーク VNet のすべてのコンポーネントが専用リソースグループに含まれています。

1 つの VNet、
ネットワークアプリケーションファイアウォール（WAF）を含むAzureアプリケーションゲートウェイ（アプリケーションGW）
データベース、アプリケーション、フロントエンド層の 3 つのネットワークセキュリティグループ (図では "NSG" で名前が付けられています)
2 つのアプリケーションセキュリティグループ (図では "ASG" という名前)
2 つのプライベートエンドポイント

さらに、ハブ VNet のリソースは、適切な接続サブスクリプションにデプロイされます。

この記事の内容

ゼロトラスト原則は、テナントとディレクトリレベルから、アプリケーションセキュリティグループへの VM の割り当てまで、アーキテクチャ全体に適用されます。以下の表は、このアーキテクチャを保護するための推奨事項を記述したものである。

ステップ	タスク
1	Microsoft Entra RBAC を利用するか、ネットワークリソースのカスタムロールを設定します。
2	インフラストラクチャを独自のリソースグループに分離します。
3	サブネットごとにネットワークセキュリティグループを作成する。
4	VNet 内のトラフィックとリソースをセキュリティで保護します。ネットワークセキュリティグループのベースライン拒否規則をデプロイします。 VNet への管理トラフィックを計画します。ネットワークセキュリティグループのフローロギングを配置する。
5	Azure PaaS サービスのイングレスとエグレスをセキュリティで保護します。
6	VNet とアプリケーションへの安全なアクセス。
7	高度な脅威検出、アラート、保護を可能にします。

このガイドでは、Azure アプリlication Service と Azure SQL Database が独自のリソースグループに既にデプロイされていることを前提としています。

ステップ 1：Microsoft Entra RBAC を活用するか、ネットワークリソースのカスタムロールを設定する

ネットワーク共同作成者には、Microsoft Entra RBAC 組み込みロールを利用できます。ただし、もう 1 つの方法は、カスタムロールを活用することです。スポーク VNet ネットワークマネージャーは、Microsoft Entra RBAC ネットワーク共同作成者ロールによって付与されたネットワークリソースへのフルアクセスは必要ありませんが、他の一般的なロールよりも多くのアクセス許可が必要です。カスタムロールを使用して、必要なものだけにアクセスのスコープを設定できます。

これを実装する簡単な方法の 1 つは、Azure ランディングゾーン参照アーキテクチャにあるカスタムロールをデプロイすることです。

使用できる特定のロールは、次のアクセス許可を持つネットワーク管理 カスタムロールです。

スコープですべてを読む
ネットワークプロバイダとのアクション
サポートプロバイダーとのアクション
リソースプロバイダーを使用したアクション

このロールは、Azure ランディングゾーン参照アーキテクチャ GitHub リポジトリのスクリプトを使用して作成することも、Azure カスタムロールを持つ Microsoft Entra ID を使用して作成することもできます。

ステップ 2：インフラストラクチャを独自のリソースグループに分離する

ネットワーク・リソースをコンピュート、データ、ストレージ・リソースから分離することで、パーミッションが流出する可能性を減らすことができる。さらに、すべての関連リソースが 1 つのリソースグループ内にあることを確認することで、1 つのセキュリティ割り当てを行うことができ、これらのリソースへのロギングとモニタリングをより適切に管理することができます。

共有リソースグループ内の複数のコンテキストでスポークネットワークリソースを使用できるようにする代わりに、専用のリソースグループを作成します。次のアーキテクチャの図は、この構成を示しています。

この図では、参照アーキテクチャ全体のリソースとコンポーネントが、アプリケーションサービス、Azure SQL データベース、ストレージアカウント、ハブ VNet リソース、スポーク VNet リソース用の専用リソースグループに分割されています。

専用のリソースグループでは、Azure portal チュートリアルを使用して、Azure リソースへのアクセス権をユーザーに付与する方法を使用してカスタムロールを割り当てることができます。

追加の推奨事項:

指定された個人ではなく、ロールのセキュリティグループを参照する。
エンタープライズ ID 管理プラクティスを使用して、セキュリティグループへのアクセスを管理します。

リソースグループ上でログ転送を適用するポリシーを使用していない場合は、以下のようにリソースグループのアクティビティログでこれを構成します。

Azure portal でリソースグループを見つけます。
[アクティビティログ - >アクティビティログのエクスポート] に移動し、[+ 診断設定の追加]を選択します。
[診断設定] 画面で、すべてのログカテゴリ (特にセキュリティ) を選択し、監視用の Log Analytics ワークスペースや長期ストレージ用のストレージアカウントなど、適切なログソースに送信します。次に例を示します。

これらのログとアラートを確認する方法については、診断設定を参照してください。

サブスクリプションの民主化

ネットワークとは直接関係ありませんが、サブスクリプションの RBAC も同様の方法で計画する必要があります。リソースをリソースグループごとに論理的に分離することに加えて、ビジネスエリアとポートフォリオオーナーに基づいてサブスクリプションを分離する必要があります。管理単位としてのサブスクリプションは、スコープを狭くする必要があります。

詳細については、「Azure ランディングゾーンの設計原則」を参照してください。

ステップ 3：サブネットごとにネットワークセキュリティグループを作成する

Azureネットワークセキュリティグループは、Azure VNet内のAzureリソース間のネットワークトラフィックをフィルタリングするために使用される。各サブネットにネットワークセキュリティグループを適用することが推奨されます。これは、Azure ランディングゾーンをデプロイするときに、既定で Azure ポリシーによって適用されます。ネットワークセキュリティグループには、複数の種類のAzureリソースに対する受信ネットワークトラフィック、または複数の種類のAzureリソースからの送信ネットワークトラフィックを許可または拒否するセキュリティ標準が含まれています。ルールごとに、送信元と宛先の IP アドレス、プロトコル (TCP や UDP など)、ポートを指定できます。

多層アプリケーションの場合は、ネットワークコンポーネントをホストするサブネットごとに専用のネットワークセキュリティグループ (次の図の "NSG") を作成することをお勧めします。

図の説明：

アプリケーションの各層には、Web 層用とデータ層用の 1 つなど、専用のイングレスサブネットがあります。
Azure アプリlication Services には、特定のアプリケーションサービス専用のエグレスサブネットがあります。
これらのサブネットごとにネットワークセキュリティグループが構成されます。

図とは異なる方法でネットワークセキュリティグループを構成すると、ネットワークセキュリティグループの一部またはすべてを正しく構成できない可能性があり、トラブルシューティングで問題が発生する可能性があります。また、監視や記録も難しくなる。

ネットワークセキュリティグループの設定を管理するには、「Azure ネットワークセキュリティグループの作成、変更、または削除」を参照してください。

ネットワークセキュリティグループの詳細については、環境のセキュリティ保護に使用する方法を理解してください。

ステップ 4：VNet 内のトラフィックとリソースをセキュリティで保護する

このセクションでは、次の推奨事項について説明します。

ネットワークセキュリティグループのベースライン拒否ルールを導入する
アプリケーション固有のルールをデプロイする
VNet における管理トラフィックの計画
ネットワークセキュリティグループのフローロギングを配置する

ネットワークセキュリティグループのベースライン拒否ルールを導入する

ゼロトラストの重要な要素は、必要最小限のアクセスレベルを使用することです。既定では、ネットワークセキュリティグループには許可規則があります。拒否規則のベースラインを追加することで、最小レベルのアクセスを適用できます。プロビジョニングが完了したら、優先順位が 4096 の受信規則と送信規則のそれぞれですべての拒否規則を作成します。これは、使用可能な最後のカスタム優先度です。つまり、許可アクションを構成するための再メインスコープが残っていることを意味します。

これを行うには、ネットワークセキュリティグループで、[送信ドセキュリティルール] に移動し、[追加] を選択します。以下を記入する：

ソース：Any
ソースポート範囲： *
宛先： Any
サービス：カスタム
宛先ポート範囲：*
プロトコル：Any
アクション：拒否
優先度：4096
名前：DenyAllOutbound
説明：明示的に許可されていない限り、すべての送信トラフィックを拒否します。

次に例を示します。

インバウンドルールでこのプロセスを繰り返し、必要に応じて名前と説明を調整する。

[受信セキュリティ規則] タブには、規則に対する警告サインオンが表示されます。次に例を示します。

ルールをクリックし、一番下までスクロールして詳細を表示します。次に例を示します。

次に、2 つの警告メッセージが表示されます。

デフォルトでは、Azureロードバランサーはこのネットワークセキュリティグループを使用してリソースにアクセスできません。
既定では、この VNet 上の他のリソースは、このネットワークセキュリティグループを使用してリソースにアクセスできません。

ゼロトラストの目的のためにば、こうあるべきなのだ。つまり、この VNet 上に何かがあるからといって、リソースにすぐにアクセスできるわけではありません。トラフィックパターンごとに、明示的に許可するルールを作成します。最小限のアクセス許可で行う必要があります。

Active Directory ドメインサービス (AD DS) の実行、コントローラーメインプライベート DNS VM、特定の外部 Web サイトなど、管理用の特定の送信接続がある場合は、ここで制御する必要があります。

代替拒否規則

Note

このセクションの推奨事項は、Web エグレスサブネットにのみ適用されます。

Azure Firewall を使用して送信接続を管理している場合は、deny-outbound-all を実行する代わりに、送信接続の代替規則を作成できます。 Azureファイヤウォールの実装の一環として、既定のルート (0.0.0.0/0) トラフィックをファイアウォールに送信するルートテーブルを設定します。これにより、VNet の外部のトラフィックが処理されます。

その後、すべての VNet 送信規則を拒否するか、すべての送信規則を許可しますが、受信規則を使用してアイテムをセキュリティで保護することができます。

環境のセキュリティをさらに強化するために使用する方法については、 Azureファイヤウォールとルートテーブルに関するページを参照してください。

アプリケーション固有のルールをデプロイする

最小限の権限で、明示的に許可された経路のみをたどるトラフィック・パターンを定義する。サブネットをソースとして使用して、ネットワークセキュリティグループでネットワークパターンを定義します。次に例を示します。

「ネットワークセキュリティグループの管理」を使用：セキュリティルールプロセスを作成して、ネットワークセキュリティグループにルールを追加します。

このシナリオをセキュリティで保護するには、次の規則を追加します。

サブネットのネットワークセキュリティグループ	方向	ソース	ソースの詳細	発信元ポート	宛先	宛先の詳細	サービス	ネットワークセキュリティグループ名	ネットワークセキュリティグループの説明
アプリサービスサブネット	着信	IP アドレス	アプリlication Gateway サブネットのプライベート IP アドレス範囲	443	IP アドレス	アプリ Service のプライベートエンドポイントの明示的な IP アドレス	MS SQL	AllowGWtoアプリInbound	アプリlication Gateway からアプリ Service への受信アクセスを許可します。
アプリ Service 統合サブネット	発信	IP アドレス	アプリ Service 統合サブネットの IP アドレス範囲	1433	IP アドレス	SQL DB のプライベートエンドポイントの明示的な IP アドレス	MS SQL	AllowアプリtoSQLDBOutbound	アプリ Service Integration サブネットから SQL プライベートエンドポイントへの送信アクセスを許可します。
Azure SQL サブネット	着信	IP アドレス	アプリ Service 統合サブネットの IP アドレス範囲	1433	IP アドレス	SQL DB のプライベートエンドポイントの明示的な IP アドレス	MS SQL	AllowアプリtoSQLDBInbound	アプリ Service Integration サブネットから SQL プライベートエンドポイントへの受信アクセスを許可します。

Note

ソーストラフィックが異なるポートから送信される場合があり、このパターンが発生した場合は、ソースポート範囲を「*」に追加して、任意のソースポートを許可できます。宛先ポートの方が重要であり、ソースポートには常に「*」を使用することをお勧めします。

Note

優先順位には、100 ～ 4000 の値を使用します。 105から始められます。

これは、アプリlication Gateway サブネットのネットワークセキュリティグループ規則に加えて行われます。

これらの規則では、1 つのアプリケーション層に対してゼロトラスト接続パターンを定義しました。追加のフローの必要に応じて、このプロセスを繰り返すことができます。

VNet における管理トラフィックの計画

アプリケーション固有のトラフィックに加えて、管理トラフィックを計画します。ただし、通常、管理トラフィックはスポーク VNet の外部から送信されるため、より多くのルールが必要です。まず、管理トラフィックの送信元となる特定のポートとソースを理解します。通常、すべての管理トラフィックは、スポークのハブネットワークにあるファイアウォールまたはその他のネットワークバーチャルアプライアンス (NVA) から流れる必要があります。

完全なリファレンスアーキテクチャについては、「Azure IaaS にゼロトラスト原則を適用する」の概要を参照してください。

構成は、特定の管理ニーズによって異なります。ただし、ファイアウォールアプライアンスの規則とネットワークセキュリティグループの規則を使用して、プラットフォームネットワーク側とワークロードネットワーク側の両方で接続を明示的に許可する必要があります。

デプロイの計画

アプリケーションサービスとデータベースはプライベートネットワークを使用しているため、これらのリソースへのコードとデータのデプロイがどのように動作するかを計画します。プライベートビルドサーバーがこれらのエンドポイントにアクセスできるようにする規則を追加します。

ネットワークセキュリティグループのフローロギングを配置する

ネットワークセキュリティグループが不要なトラフィックをブロックしている場合でも、目標が満たされているわけではありません。攻撃を検出するには、明示的なパターンの外部で発生しているトラフィックを観察する必要があります。

プライベートエンドポイントへのトラフィックはログに記録されません が、他のサービスが後でサブネットにデプロイされている場合、このログはアクティビティの検出に役立ちます。

ネットワークセキュリティグループフローのログ記録を有効にするには、「チュートリアル：プライベートエンドポイントの既存のネットワークセキュリティグループのバーチャルマシンとの間でネットワークトラフィックフローをログに記録する」に従います。

Note

次の推奨事項に留意してください。

必要に応じてログへのアクセスを制限する必要があります。
ログは、必要に応じて Log Analytics と Microsoft Sentinel に送られる必要があります。

ステップ 5：Azure PaaS サービスのイングレスとエグレスをセキュリティで保護する

このセクションには、PaaS サービスのイングレスとエグレスをセキュリティで保護するために必要な 2 つのステップが含まれています。

サービスへのイングレス用のプライベートエンドポイントをデプロイします。
VNet 統合をデプロイして、アプリlication Service が VNet と通信できるようにします。

さらに、名前の解決を可能にする DNS 構成も検討する必要があります。

イングレス用のプライベートエンドポイントをデプロイする

多くのサービスでは、Azure portal のリソース固有のブレードからプライベートエンドポイントを作成できますが、より一貫性のあるエクスペリエンスは、独自のリソースの作成からプライベートエンドポイントを作成することです。そのためには、リソースが既にデプロイされている必要があります。デプロイしたら、プライベートエンドポイントを作成できます。

プライベートエンドポイントをデプロイするときは、次のように構成します。

親リソースを格納する特定のリソースグループに配置して、リソースを同様のライフサイクルに保ち、一元的なアクセスを提供します。
ロールに基づいて、VNet 内の適切なサブネットに配置します。
Azure アプリlication Service では、通常のフロントエンドとその SCM エンドポイントの両方に対してプライベートエンドポイントを構成できます。これは、デプロイと管理に使用されます。

また、このデプロイの一環として、サービス固有のファイアウォールが受信トラフィックを拒否するように設定されていることを確認する必要があります。これにより、パブリックイングレスでの試行は拒否されます。

Azure SQL データベースの場合は、サーバーレベルの IP ファイアウォールルールを管理します。 Azure portal のネットワークパネルからパブリックネットワークアクセスが[無効] に設定されていることを確認します。

Azure アプリlication Service の場合、プライベートエンドポイントを追加すると、既定で受信アクセスをブロックするようにサービスレベルのファイアウォールが設定されます。詳細については、「アプリ Service アプリのプライベートエンドポイントの使用」を参照してください。

エグレス用に VNet 統合をデプロイする

イングレス用のプライベートエンドポイントに加えて、VNet 統合を有効にします。各アプリ Service プランで VNet 統合を有効にすることができ、これにより、アプリ Service のサブネット全体が割り当てられます。詳細については、「アプリを Azure VNet と統合する」を参照してください。

アプリ Service を構成するには、「Azure アプリ Service で VNet 統合を有効にする」を参照してください。これをエグレス用に指定されたサブネット内に配置していることを確認します。

DNS の考慮事項

プライベートエンドポイントの使用の一環として、リソースの FQDN の新しいプライベート IP アドレスへの DNS 解決を有効にします。さまざまな方法でこれを実装する手順については、プライベートエンドポイントの DNS 構成に関する記事を参照してください。

Note

DNS 解決はすべてのトラフィックに適用する必要があります。同じ VNet 内のリソースは、正しい DNS ゾーンを使用していない限り解決できません。

ステップ 6：VNet とアプリケーションへの安全なアクセス

VNet とアプリケーションへのアクセスをセキュリティで保護するには、次のものが含まれます。

Azure 環境内のアプリケーションへのトラフィックをセキュリティで保護する
アプリケーションへのユーザーアクセスに対する多要素認証 (MFA) と条件付きアクセスポリシーの使用。

次の図は、参照アーキテクチャ全体の両方のアクセスモードを示しています。

VNet とアプリケーションの Azure 状態でのトラフィックをセキュリティで保護する

Azure 状態でのトラフィックをセキュリティで保護するための作業のほとんどは既に完了しています。ストレージリソースと VM 間のセキュリティで保護された接続を構成するには、Azure ストレージにゼロトラスト原則を適用する方法に関するページを参照してください。

ハブリソースから VNet へのアクセスをセキュリティで保護するには、Azure のハブ VNet にゼロトラスト原則を適用する方法に関するページを参照してください。

アプリケーションへのユーザーアクセスに MFA ポリシーと条件付きアクセスポリシーを使用する

バーチャルマシンへのゼロトラスト原則の適用に関する記事では、MFA と条件付きアクセスを使用して VM へのアクセス要求を直接保護する方法を推奨しています。これらのリクエストは、管理者や開発者からのものである可能性が高い。次のステップでは、MFA と条件付きアクセスを使用してアプリケーションへのアクセスをセキュリティで保護します。これは、アプリケーションにアクセスするすべてのユーザーに適用されます。

まず、アプリケーションがまだ Microsoft Entra ID と統合されていない場合は、Microsoft ID プラットフォームのアプリケーションの種類を参照してください。

次に、ID とデバイスのアクセスポリシーのスコープにアプリケーションを追加します。

条件付きアクセスと関連ポリシーを使用して MFA を構成する場合は、ゼロトラストに推奨されるポリシーセットをガイドとして使用します。これには、デバイスの管理を必要としない開始点ポリシーが含まれます。 VM にアクセスするデバイスが管理され、エンタープライズレベルを実装できるのが理想的です。これは、ゼロトラストに推奨されます。詳細については、「共通のゼロトラスト ID およびデバイスアクセスポリシー」を参照してください。

以下の図は、ゼロ・トラストの推奨方針を示している。

ステップ 7：高度な脅威の検出と保護を有効にする

Azure 上に構築されたスポーク VNet は、Azure またはオンプレミスで実行されている IT ビジネス環境の他のリソースも保護される可能性があるため、Microsoft Defender for Cloudによって保護される場合があります。

このシリーズの他の記事でメンションように、Defender for Cloud はクラウドセキュリティ体制管理 (CSPM) およびクラウドワークロード保護 (CWP) ツールであり、セキュリティに関する推奨事項、アラート、クラウドセキュリティ体験の進行に役立つアダプティブネットワークのセキュリティ強化などの高度な機能を提供します。

この記事では Defender for Cloud については詳しく説明しませんが、Defender for Cloud は、Azure ポリシーと Log Analytics ワークスペースに取り込まれたログに基づいて動作することを理解しておくことが重要です。スポーク VNet と関連リソースを使用してサブスクリプションで有効にすると、そのセキュリティ体制を改善するための推奨事項を確認できます。これらの推奨事項は、MITRE 戦術、リソースグループなどによってさらにフィルター処理できます。組織のセキュリティスコアに大きな影響を与える推奨事項を解決するには、優先順位付けを検討してください。次に例を示します。

高度なワークロード保護を提供する Defender for Cloud プランが存在し、これには既存のネットワークセキュリティグループ規則を改善するためのアダプティブネットワークのセキュリティ強化に関する推奨事項が含まれています。次に例を示します。

推奨事項を受け入れるには、[適用] を選択します。この場合、新しいネットワークセキュリティグループ規則が作成されるか、既存の規則が変更されます。

次のステップ

azure にゼロトラスト標準を適用する場合は、次の追加の記事を参照してください。

次の方法で共有

Azure PaaS サービスを使うスポークバーチャルネットワークにゼロトラスト原則を適用する

Azure PaaS サービス用のゼロトラストスタンドアロンまたはスポークネットワーク

参照アーキテクチャ

この記事の内容

ステップ 1：Microsoft Entra RBAC を活用するか、ネットワークリソースのカスタムロールを設定する