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

概要: Azure のスポーク仮想ネットワークにゼロ トラストの原則を適用するには、ロールベースのアクセス制御 (RBAC) を利用し、サブネットと仮想マシン (リソース グループ、ネットワーク セキュリティ グループ、アプリケーション セキュリティ グループ) を分離し、VNet および仮想マシン アプリケーション内のトラフィックとリソースをセキュリティで保護し、高度な脅威検出、アラート、保護を有効にする必要があります。

この記事では、AzureのIaaSワークロード用スポークバーチャルネットワーク（VNet）にゼロトラストの原則を適用する方法について、以下のように説明します：

ゼロ トラストの標準	定義	以下により適合
明示的に検証する	常に利用可能なすべてのデータポイントに基づいて認証および承認してください。	アプリケーションセキュリティグループを使用して、個々のNICが特定のチャネルで通信する権限を持っていることを確認します。
最小限の特権アクセスを使用する	ジャスト・イン・タイムおよびジャスト・エナフ・アクセス（JIT/JEA）、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。	どのチャンネルでもデフォルトで3389/RDPアクセスを有効にしないでください。 スポークされたコンテキストに正しいロール権限を使用してください。
侵害を前提とする	影響範囲を最小限に抑えるために、アクセスをセグメント化します。 エンドツーエンドの暗号化を検証し、分析を使用して可視性を得て、脅威検出を促進し、防御を強化します。	リソース間の不要な通信を制限します。 ネットワーク セキュリティ グループにログインできることと、異常なトラフィックが適切に可視化できるようにする。 ネットワークセキュリティグループの変更を追跡します。

この記事は、バーチャルマシンベースのワークロードをホストするスポーク VNet を含む Azure の環境全体にゼロ トラストの原則を適用する方法を示す一連の記事の一部です。 詳細については、「Azure IaaS にゼロ トラスト原則を適用する」の概要を参照してください。

リファレンス アーキテクチャ

以下の図は、IaaSベースのワークロードの一般的なリファレンスアーキテクチャを示している。

図の説明：

• VNetスポーク には、バーチャルマシンで構成される IaaS アプリケーションをサポートするコンポーネントが含まれています。
• IaaSアプリケーションは、フロントエンド、アプリケーション、データの各層ごとに2つのバーチャルマシンで構成される3層アプリケーションである。
• 各層には、専用のネットワーク・セキュリティ・グループ用の専用サブネットが含まれています。
• 各バーチャルマシンのロールは、そのロールに対応するアプリケーション セキュリティ グループに割り当てられます。
• アプリケーションへのアクセスは、独自のサブネットに含まれるアプリケーションゲートウェイを介して提供されます。

リファレンス・アーキテクチャで示したアプリケーションは、N 層アーキテクチャ・スタイルに従っている。

次の図は、ハブ VNet 用のサブスクリプションとは別に、Azure サブスクリプション内のスポーク VNet 用のリソースグループのコンポーネントを示している。

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

• 1 つの VNet、
• ネットワークアプリケーションファイアウォール（WAF）を含むAzureアプリケーションゲートウェイ（アプリケーションGW）
• 3 つのネットワーク セキュリティ グループ (アプリケーション層ごとに 1 つ)。
• 3 つのアプリケーション セキュリティ グループ (アプリケーション層ごとに 1 つ)。

この記事の内容

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

ステップ	タスク	適用されるゼロトラストの原則
1	Microsoft Entra のロールベースのアクセス制御 (RBAC) を使用するか、ネットワーク リソースのカスタム ロールを設定します。	最小限の特権アクセスを使用する
2	インフラストラクチャを独自のリソース グループに分離します。	侵害を前提とする
3	サブネットごとにネットワーク セキュリティ グループを作成する。	最小限の特権アクセスを使用する 侵害を前提とする
4	バーチャルマシンのアプリケーション セキュリティ グループを作成します。	明示的に検証する 最小限の特権アクセスを使用する 侵害を前提とする
5	VNet 内のトラフィックとリソースをセキュリティで保護します。 ネットワークセキュリティグループのベースライン拒否ルールを導入する アプリケーション セキュリティ グループのアプリケーション固有のルールを導入する VNetにおける管理トラフィックの計画 ネットワーク セキュリティ グループのフロー ログをデプロイする IDPS で受信 Web トラフィックを保護する	明示的に検証する 最小限の特権アクセスを使用する 侵害を前提とする
6	VNet とアプリケーションへの安全なアクセス。	最小限の特権アクセスを使用する 侵害を前提とする
7	高度な脅威検出、アラート、保護を可能にします。	侵害を前提とする

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

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

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

具体的なロールは、ネットワーク管理ロールであり、以下の権限を持つ：

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

このロールは、カスタム ロールのスクリプトを使用するか、Azure カスタム ロール (Azure RBAC) で説明されているプロセスで Microsoft Entra ID を使用して作成できます。

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

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

スポーク・ネットワーク・リソースを共有リソース・グループ内の複数のコンテキストで利用できるようにするのではなく、専用のリソース・グループを作成します。 本記事がサポートするリファレンスアーキテクチャは、このコンセプトを示している。

図では、リファレンス・アーキテクチャ全体のリソースとコンポーネントが、バーチャルマシン、ストレージ・アカウント、ハブVNetリソース、およびスポークVNetリソースの専用リソース・グループに分割されています。

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

追加の推奨事項:

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

リソース グループにログ転送を適用するポリシーを使用していない場合は、リソース グループのアクティビティ ログでこれを構成します。[アクティビティ ログ>のエクスポート アクティビティ ログ]に移動し、[+ 診断設定の追加] を選択します。

[診断設定] 画面で、すべてのログ カテゴリ (特にセキュリティ) を選択し、監視用の Log Analytics ワークスペースや長期ストレージ用のストレージ アカウントなど、適切なログ ソースに送信します。

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

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

サブスクリプションの民主化の詳細については、「Azure ランディング ゾーンの設計原則 - クラウド導入フレームワーク」を参照してください。

ここに示すように、Azure Monitorの診断設定のセキュリティカテゴリから診断を構成します。

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

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

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

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

図の説明：

• アプリケーションの各層は、フロントエンド層、アプリ層、データなどの専用サブネットでホストされます。
• これらのサブネットごとにネットワークセキュリティグループが構成されます。

ネットワーク・セキュリティ・グループを図と異なる方法で設定すると、ネットワーク・セキュ リティ・グループの一部または全部が正しく設定されず、トラブルシューティングで問 題が発生することがあります。 また、監視や記録も難しくなる。

このプロセスを使用して、ネットワーク セキュリティ グループを作成します： Azureネットワークセキュリティグループの作成、変更、削除

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

ステップ 4：バーチャルマシンロールごとにアプリケーション セキュリティ グループを作成する

アプリケーション セキュリティ グループを使用すると、ネットワーク セキュリティをアプリケーションの構造の自然な拡張として構成でき、バーチャルマシンをグループ化して、それらのグループに基づくネットワーク セキュリティ ポリシーを定義できます。 明示的な IP アドレスを手動でメンテナンスせずに、大きなセキュリティ ポリシーを再利用することができます。 このプラットフォームは、明示的なIPアドレスと複数のルールセットの複雑さを処理するため、ビジネスロジックに集中することができます。

ワークロード内で、特定のバーチャルマシンのロールを特定します。 次に、役割ごとにアプリケーションセキュリティグループを作成します。 参照アーキテクチャには、3 つのアプリケーション セキュリティ グループがあります。

図の説明：

• このアプリをサポートするために、フロントエンド、アプリ、データの 3 つのアプリケーション セキュリティ グループ (各層に 1 つ) が作成されます。
• 各バーチャルマシンは、その役割に対応するアプリケーション・セキュリティ・グループに割り当てられる（図の赤文字）。

アプリケーションセキュリティグループの詳細とバーチャルマシンへの割り当て方法については、Azure アプリケーションセキュリティグループの概要を参照してください。

Note

ロード バランサーを使用している場合は、アプリケーション セキュリティ グループでロード バランサーのスコープを設定できないため、ネットワーク セキュリティ グループでロード バランサーの IP アドレスを使用する必要があります。

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

このセクションでは、以下の推奨事項を取り上げる：

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

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

ゼロトラストの重要な要素は、必要最小限のアクセスレベルを使用することです。 デフォルトでは、ネットワーク・セキュリティ・グループには許可ルールがある。 拒否規則のベースラインを追加することで、最小レベルのアクセスを適用できます。

プリプロビジョニング後、各インバウンドおよびアウトバウンドルールに、優先度4096のすべて拒否するルールが作成される。 これは使用可能な最後のカスタム優先度であるため、許可アクションを構成するためのスコープがまだ残っていることを意味します。

ネットワークセキュリティグループで、アウトバウンドセキュリティルールに移動し、[追加]を選択します。 以下を記入する：

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

次に例を示します。

インバウンドルールでこのプロセスを繰り返し、必要に応じて名前と説明を調整する。 インバウンドセキュリティルールタブには、ここに示すようにルールに警告サインがあることに気付くでしょう。

ルールをクリックして一番下までスクロールすると、以下に示すように詳細が表示されます。

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

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

ゼロ トラストの目的のためにば、こうあるべきなのだ。 つまり、この VNet 上に何かがあるからといって、そのリソースにすぐにアクセスできるわけではないということだ。 各トラフィックパターンに対して、それを明示的に許可するルールを作成する必要があり、最小限の権限でそうする必要がある。 したがって、Active Directoryドメインサービス（AD DS）ドメインコントローラー、プライベートDNSバーチャルマシン、特定の外部ウェブサイトなど、管理用の特定のアウトバウンド接続がある場合は、ここで制御する必要がある。

代替拒否ルール

Azureファイアウォールを使用してアウトバウンド接続を管理する場合、すべてのアウトバウンド拒否を実行する代わりに、すべてのアウトバウンドを開いたままにすることができます。 Azureファイアウォールの実装の一環として、VNet外のトラフィックを処理するファイアウォールにデフォルトのルート（0.0.0.0/0）を送信するルーティングテーブルを設定します。

その後、すべての VNet 送信を拒否するか、代わりにすべての送信を許可します (ただし、受信標準を使用してアイテムをセキュリティで保護します)。

Azureファイアウォールとルーティングテーブルの詳細については、これらを使用して環境のセキュリティをさらに向上させる方法をご覧ください。

バーチャルマシンの管理ルール

Microsoft Entraのログイン、マルウェア対策、および自動アップデートを有効にしてバーチャルマシンを構成するには、次の送信接続を許可する必要があります。 これらの多くはFQDNによって提供される。つまり、FQDNルールにはAzureファイアウォールが必要であり、そうでなければもっと複雑なプランが必要になる。 Azureファイアウォールの使用をお勧めします。

警告

これらを代わりにハブ ネットワークに移動することが必要な場合があります。

アウトバウンド接続は以下の通り：

• を443番ポートに接続する：
  • enterpriseregistration.windows.net
  • settings-win.data.microsoft.com
  • sls.update.microsoft.com
  • v10.events.data.microsoft.com
  • login.microsoftonline.com
  • pas.windows.net
  • 169.254.169.254
• を80番ポートに接続する：
  • ctldl.windowsupdate.com
  • www.msftconnecttest.com
• を123番ポートに接続する：
  • time.windows.com
• を1688番ポートに接続する：
  • Azkms.core.windows.net

アプリケーション セキュリティ グループのアプリケーション固有のルールを導入する

最小限の権限で、明示的に許可された経路のみをたどるトラフィック・パターンを定義する。 アプリケーション・セキュリティ・グループを使用して、ハブ VNet とともに使用されるスポーク VNet のネットワーク・セキュリティ・グループにネットワーク・トラフィック・パターンを定義する例を図に示します。 これが推奨される構成である。

別の例として、ネットワークアプリケーションファイアウォールがスポークVNetのアプリケーションゲートウェイサブネットに配置されるスタンドアロンスポークVNetの構成があります。

次のネットワーク セキュリティ グループ標準が必要です。

1. APP GW サブネット(HTTPS 443)へのインターネット トラフィックを許可します。
2. APP GW サブネットからフロントエンド層バーチャルマシンへのトラフィックを許可する (HTTPS 433)。
3. フロントエンド層バーチャルマシンからアプリ層ロード バランサーへのトラフィックを許可する (HTTPS 443)。
4. アプリ層ロードバランサーからアプリ層バーチャルマシンへのトラフィックを許可する(HTTPS 443)。
5. アプリ層バーチャルマシンからデータロード バランサーへのトラフィックを許可する (SQL 1433)。
6. データロード バランサーからデータバーチャルマシンへのトラフィックを許可する (SQL 1433)。
7. データバーチャルマシン間のトラフィックを許可する (SQL 1433)

最初に SQL パターンを構成し、残りの階層でこのプロセスを繰り返す。 以下のセクションは、単一のアプリケーション層のネットワークトラフィックを制限するルールの設定である。

ルール5 - アプリ層のバーチャルマシンからデータのロードバランサーへのトラフィックを許可する（SQL 1433）

アプリケーション層サブネットのネットワークセキュリティグループで、インバウンドセキュリティルールに移動し、[追加]を選択します。 リストには以下を入力する：

• ソース: アプリケーション セキュリティ グループ
• ソース アプリケーション セキュリティ グループ: ビジネス層アプリケーション セキュリティ グループを選択します。
• ソースポートの範囲 1433 (ソーストラフィックが異なるポートから来ることがあり、このパターンが発生した場合は、ソースポート範囲を * に追加して、任意のソースポートを許可することができます。送信先ポートはより重要であり、送信元ポートには常に*を使用することをお勧めします)
• 宛先: IP アドレス
• 宛先 IP アドレス/CIDR 範囲: ロード バランサーの明示的な IP
  • ここでは、ロード バランサーをアプリケーション セキュリティ グループに関連付けることができないため、明示的な IP を使用する必要があります。
  • IP スキーマを計画するか、ロード バランサーをデプロイして、割り当てられている IP を参照できます。
• サービス: MS SQL
• 宛先ポート範囲：これは、ポート 1433 に対して自動的に入力されます
• プロトコル：これは TCP に対して自動的に選択されます
• アクション:許可する
• 優先度 – 100 から 4096の間の値。 105 から始めることができます。
• ファイルの名前: Allow-App-Tier-to-Data-LB-Inbound
• 説明: データロード バランサーからアプリ層のバーチャルマシンへの受信アクセスを許可する。

完了後、ルールに関する情報アラートのための青いアイコンが表示されることに気付くでしょう。 ルールをクリックすると、次のメッセージが表示される。

• "アプリケーション セキュリティ グループを使用する標準は、アプリケーション セキュリティ グループが同じバーチャルネットワーク上のネットワーク インターフェイスに関連付けられている場合にのみ適用できます。"

次に例を示します。

このルールは、このアプリケーションセキュリティグループがこのネットワークで使用されている場合にのみ適用される。

最後に、同じネットワーク セキュリティ グループで、[アウトバウンド セキュリティ標準]に移動し、[追加]を選択します。 例に似たリストを作成し、[インバウンド]を[アウトバウンド]に変更します。

ルール6 - データのロードバランサーからデータのバーチャルマシンへのトラフィックを許可する（SQL 1433）

データ層サブネットのネットワークセキュリティグループで、インバウンドセキュリティルール‭‬に移動し、‭‬[追加]‭‬を選択します。 リストには以下を入力する：

• ソース: IP アドレス
• ソース IP : ロード バランサーの IP アドレス
• ソース ポート範囲: 1433
• 宛先アプリケーションセキュリティ グループ
• 宛先アプリケーション セキュリティ グループ: データアプリケーション セキュリティ グループを選択する
• サービス: MS SQL
• 宛先ポート範囲：これは、ポート 1433 に対して自動的に入力されます。
• プロトコル：これは TCP に対して自動的に選択されます。
• アクション:許可する
• 優先度 – 100 から 4096の間の値。 105 から始めることができます。
• 文件名前: Allow-SQL-LB-to-SQL-VMs-Inbound
• 説明: データロード バランサーから SQL ベースのデータバーチャルマシンへの受信アクセスを許可する。

同じネットワーク セキュリティ グループで、[アウトバウンド セキュリティ標準]に移動し、[追加]を選択します。 例のようにリストに入力し、[インバウンド]を[アウトバウンド]に変更します。

ルール7 - データバーチャルマシン間のトラフィックを許可する（SQL 1433）

データ層サブネットのネットワークセキュリティグループで、インバウンドセキュリティルール‭‬に移動し、‭‬[追加]‭‬を選択します。 リストには以下を入力する：

• ソース: アプリケーション セキュリティ グループ
• 宛先アプリケーション セキュリティ グループ: データアプリケーション セキュリティ グループを選択する
• ソース ポート範囲: 1433
• 宛先アプリケーションセキュリティ グループ
• 宛先アプリケーション セキュリティ グループ: データアプリケーション セキュリティ グループを選択する
• サービス: MS SQL
• 宛先ポート範囲：これは、ポート 1433 に対して自動的に入力されます。
• プロトコル：これは TCP に対して自動的に選択されます。
• アクション:許可する
• 優先度 – 100 から 4096の間の値。 105 から始めることができます。
• ファイル名前: Allow-SQL-VM-to-SQL-VM-Inbound
• 説明: SQL ベースのデータバーチャルマシン間の受信アクセスを許可する。

同じネットワーク セキュリティ グループで、[アウトバウンド セキュリティ標準]に移動し、[追加]を選択します。 前のリストと同様にリストを作成し、[インバウンド]を[アウトバウンド]に変更します。

これらの3つのルールにより、単一のアプリケーション層に対してゼロ信頼接続パターンが定義されました。 追加のフローの必要に応じて、このプロセスを繰り返すことができます。

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

アプリケーション固有のトラフィックに加えて、トラフィック管理も計画する必要があります。 しかし、管理トラフィックは一般にスポークVNetの外部で発生する。 追加のルールが必要です。 まず、管理トラフィックがどのようなポートやソースから来るのかを理解する必要がある。 一般に、すべての管理トラフィックは、スポーク用のハブ ネットワークにあるファイアウォールまたはその他の NVA から流れるべきである。

ゼロトラスト原則のAzure IaaSへの適用概要の記事で、完全なリファレンスアーキテクチャを参照してください。

これは、それぞれの経営ニーズによって異なる。 ただし、ファイアウォールアプライアンス上のルールとネットワークセキュリティグループ上のルールを使用して、プラットフォームネットワーキング側とワークロードネットワーキング側の両方の接続を明示的に許可する必要がある。

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

ネットワーク セキュリティ グループが不要なトラフィックをブロックしている場合でも、目標が達成されているとは限りません。 明示的なパターンの外で発生しているトラフィックを観察して、攻撃が発生しているかどうかを知る必要があります。

ネットワークセキュリティグループのフローログを有効にするには、作成した既存のネットワークセキュリティグループに対して、チュートリアル：バーチャルマシンへのネットワークトラフィックフローとバーチャルマシンからのネットワークトラフィックフローのログを実行します。

Note

• ストレージ アカウントは、ストレージ ガイダンスのゼロ トラストに従う必要があります。
• 必要に応じてログへのアクセスを制限する必要があります。
• また、必要に応じてログ分析やSentinelにも流す必要がある。

IDPS で受信 Web トラフィックを保護する

スポーク仮想ネットワーク内のコントロールに加え、追加の検査を適用するために Azure Firewall を使用することもできます。 Web Application Firewall の Azure Font Door と Application Gateway 用の機能は一般的な Web 攻撃のトラフィックを検査する一方で、Azure Firewall を使用するとより深いレベルで検査を行うことができます。

使用できるすべての信号を使用し、ネットワーク トラフィックに対する一元的な可視性を保つには、Application Gateway から Azure Firewall にトラフィックをルーティングすることをお勧めします。 その後、追加の信号がないかトラフィックを検査し、その動作をログにキャプチャできます。 この構成の詳細については、「Azure Firewall と Application Gateway を使用した Web アプリケーション用のゼロ トラスト ネットワーク」の記事で確認できます。 この動作を設定する方法に関する詳しいガイダンスについては、「ゼロ トラストのために Azure Firewall Premium を構成する」を参照してください。

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

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

• Azure 状態でのアプリケーションへのトラフィックをセキュリティで保護する。
• アプリケーションへのユーザーアクセスのためにマルチファクタ認証と条件付きアクセスポリシーを使用する。

以下の図は、リファレンス・アーキテクチャ全体における、これら両方のアクセス・モードを示したものである。

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

Azure 状態でのトラフィックをセキュリティで保護するための作業のほとんどは既に完了しています。 ストレージリソースとバーチャルマシン間のセキュアな接続は、Azure ストレージにゼロトラスト原則を適用するで構成される。

ハブリソースからVNetへのアクセスを保護するには、Azureのハブバーチャルネットワークにゼロトラストの原則を適用するを参照してください。

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

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

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

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

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

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

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

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

このシリーズの他の記事メンション示されているように、Microsoft Defender for Cloud は、クラウド セキュリティ体制管理 (CSPM) とクラウド ワークロード保護 (CWP) ツールであり、セキュリティ おすすめ、アラート、アダプティブネットワーク強化などの高度な機能を提供して、クラウドセキュリティの旅を進めるのに役立ちます。 Defender for Cloud が Microsoft のセキュリティ環境に適合する場所をより適切に視覚化するには、Microsoft サイバーセキュリティリファレンスアーキテクチャを参照してください。

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

Microsoft Defender for Cloud ポータルの例です。

高度なワークロード保護を提供するDefender for Cloudプランのいずれかを選択すると、既存のネットワークセキュリティグループルールを改善するための適応型ネットワークハードニングの推奨が含まれます。 次に例を示します。

推奨事項を受け入れるには、「強制」を選択します。これにより、新しいネットワークセキュリティグループ標準が作成されるか、既存の標準が変更されます。

おすすめのトレーニング

• Azure ロールベースのアクセス制御 (Azure RBAC) を使用した Azure リソースのセキュリティ保護
• Azure Monitor の構成と管理
• ネットワーク セキュリティ グループを構成する
• ネットワーク セキュリティを設計して実装する
• Azure ID サービスを使用してアプリケーションへのセキュアなアクセス

Azure のセキュリティに関する詳細なトレーニングについては、Microsoft カタログの以下のリソースを参照してください：
Azure のセキュリティ | Microsoftの学習

次のステップ

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

• Azure IaaS の概要
  • Azure Storage
  • バーチャルマシン
  • Azure PaaS サービスを使用したスポークバーチャル ネットワーク
  • ハブバーチャルネットワーク
• Azure バーチャル デスクトップ
• Azure バーチャル WAN
• アマゾン ウェブ サービスの IaaS アプリケーション
• Microsoft Sentinel と Microsoft Defender XDR

テクニカルイラスト

このポスターでは、Azure laaS のコンポーネントを参照および論理アーキテクチャとして 1 ページで、一目で確認できるとともに、これらのコンポーネントが適用されたゼロ トラスト モデルの「決して信頼せず、常に検証する」原則を確実に満たすためのステップを示します。

アイテム	説明
PDF | Visio 更新日: 2024 年 3 月	この図をこの記事と共に使用する：Azure IaaS の概要にゼロ トラスト原則を適用する 関連ソリューションガイド Azure Storage サービス: バーチャルマシン ハブ VNet

このポスターでは、参照アーキテクチャと論理アーキテクチャ、および Azure IaaS のゼロ トラストの個別のコンポーネントの詳細な構成について説明します。 アプリケーション・セキュリティ・グループを使用して、個々の NIC が特定のチャネルで通信する権限を持っていることを確認します。このポスターのページをIT部門や専門分野に分けて使用するか、Microsoft Visio版のファイルを使用して、インフラストラクチャ用に図をカスタマイズしてください。

アイテム	説明
PDF | Visio 更新日: 2024 年 3 月	これらの図は、ここから始まる記事と一緒に使用してください：Azure IaaSの概要にゼロトラストの原則を適用する 関連ソリューションガイド Azure Storage サービス: バーチャルマシン ハブ VNet

その他の技術的な図については、ここをクリックしてください。

リファレンス

• ゼロ トラストを使用してプロアクティブなセキュリティを採用する
• ゼロ トラストによるネットワークのセキュリティ保護
• Azureファイアウォールとアプリケーションゲートウェイを使用するWebアプリケーションのゼロトラストネットワーク-Azureアーキテクチャセンター
• Azure ランディング ゾーン ポリシー
• 一般的なゼロ・トラスト・マークとデバイス・ポリシー