ネットワークと接続に関する推奨事項

[アーティクル]
11/15/2023

以下の Azure Well-Architected フレームワークセキュリティチェックリストの推奨事項に対応します。

SE:06	イングレスフローとエグレスフローの両方で、ネットワークトラフィックを分離、フィルター処理、制御する。東西と南北の両方のトラフィックで使用可能なすべてのネットワーク境界で、ローカライズされたネットワーク制御を使用して、多層防御の原則を適用します。

このガイドでは、ネットワーク設計に関する推奨事項について説明します。アーキテクチャのさまざまな深さでネットワーク境界を越える敵対者をフィルター処理、ブロック、検出できるセキュリティ制御に焦点を当てています。

ネットワークベースのアクセス制御対策を実装することで、ID 制御を強化できます。 ID ベースのアクセス制御と共に、ネットワークセキュリティは資産を保護するための優先度が高くなります。適切なネットワークセキュリティ制御では、脅威を検出して封じ込め、攻撃者がワークロードに侵入するのを防ぐのに役立つ多層防御要素を提供できます。

定義

期間	定義
東西のトラフィック	信頼された境界内を移動するネットワークトラフィック。
エグレスフロー	送信ワークロードトラフィック。
敵対的なネットワーク	ワークロードの一部としてデプロイされていないネットワーク。敵対的なネットワークは脅威ベクトルと見なされます。
イングレスフロー	受信ワークロードトラフィック。
ネットワークフィルタリング	指定された規則に基づいてネットワークトラフィックを許可またはブロックするメカニズム。
ネットワークのセグメント化または分離	ネットワークを分離された小さなセグメントに分割し、境界にセキュリティ制御を適用する戦略。この手法は、インターネットなどの敵対的なネットワークからリソースを保護するのに役立ちます。
ネットワーク変革	ネットワークパケットを隠すために変化するメカニズム。
南北のトラフィック	信頼された境界から、潜在的に敵対的な外部ネットワークに (その逆も同様) 移動するネットワークトラフィック。

主要な設計戦略

ネットワークセキュリティでは、あいまいさを使用してワークロード資産を敵対的なネットワークから保護します。ネットワーク境界の背後にあるリソースは、安全にトラフィックを進められるものとして境界制御でマークされるまで非表示になります。ネットワークセキュリティ設計は、次の 3 つの主要な戦略に基づいて構築されています。

セグメント。この手法では、境界を追加することで、個別のネットワーク上のトラフィックを分離します。たとえば、アプリケーション層との間のトラフィックは、セキュリティ要件が異なる他の層と通信するための境界を通過します。セグメント化のレイヤーにより、多層防御アプローチが実現します。

最も重要なセキュリティ境界は、アプリケーションとパブリックネットワークの間のネットワークエッジです。この境界を明確に定義して、敵対的なネットワークを分離するための境界を確立することが重要です。この境界は防御の最前線であるため、このエッジの制御は非常に効果的である必要があります。

仮想ネットワークにより、論理境界が提供されます。設計上、仮想ネットワークは、ピアリングによって意図的に境界が分割されていない限り、別の仮想ネットワークと通信できません。アーキテクチャでは、この強力なプラットフォーム提供のセキュリティ対策を利用する必要があります。

また、仮想ネットワーク内のサブネットの分割など、他の論理境界を使用することもできます。サブネットの利点は、それを使用して、分離境界内にあり、同様のセキュリティ保証を持つリソースをグループ化できることです。その後、境界で制御を構成してトラフィックをフィルター処理できます。
フィルター。この戦略は、境界に入るトラフィックが予想され、許可され、安全であることを保証するのに役立ちます。ゼロトラストの観点から、フィルター処理では、ネットワークレベルで使用可能なすべてのデータポイントを明示的に確認します。境界に規則を指定し、特定の条件を確認できます。

たとえば、ヘッダーレベルでは、トラフィックが予想される場所からのものか、予想されるボリュームがあるかを規則で確認できます。しかし、これらの確認では十分ではありません。トラフィックが予想される特性を示している場合でも、ペイロードは安全ではない可能性があります。検証チェックにより、SQL インジェクション攻撃が明らかになる可能性があります。
変革。 セキュリティ対策として、境界でパケットを変更します。 たとえば、HTTP ヘッダーを削除して、公開のリスクを排除できます。または、ある時点でトランスポート層セキュリティ (TLS) を無効にし、より厳密に管理されている証明書を使用して別のホップで再確立することもできます。

トラフィックフローを分類する

フローを分類する最初の手順は、ワークロードアーキテクチャの概略を調べることです。この概略から、ワークロードの機能ユーティリティと運用面に関して、フローの意図と特性を判断します。フローの分類に役立つ次の質問を使用します。

ワークロードが外部ネットワークと通信する必要がある場合、それらのネットワークに必要な近接通信のレベルは何ですか?
予想されるプロトコルやパケットの送信元と形状など、フローのネットワーク特性は何ですか? ネットワークレベルでコンプライアンス要件はありますか?

トラフィックフローを分類する方法は多数あります。以下のセクションでは、一般的に使用される条件について説明します。

外部ネットワークからの可視性

Public. アプリケーションとその他のコンポーネントがパブリックインターネットから到達可能な場合、ワークロードはパブリックに公開されます。アプリケーションは、1 つまたは複数のパブリック IP アドレスとパブリックドメインネームシステム (DNS) サーバーを介して公開されます。
Private. ワークロードは、仮想プライベートネットワーク (VPN) などのプライベートネットワーク経由でのみアクセスできる場合はプライベートです。 1 つまたは複数のプライベート IP アドレスを介してのみ公開されます。また、プライベート DNS サーバーを介して公開される可能性もあります。

プライベートネットワークでは、パブリックインターネットからワークロードへの通信経路はありません。ゲートウェイの場合は、ロードバランサーまたはファイアウォールを使用できます。これらのオプションではセキュリティ保証を提供できます。

パブリックワークロードの場合でも、できるだけ多くのワークロードを非公開に保つように努めます。このアプローチでは、パケットがパブリックネットワークから到着したときに、プライベート境界を通過するように強制します。そのパス内のゲートウェイは、リバースプロキシとして機能することで、遷移ポイントとして機能できます。

トラフィックの方向

イングレス。イングレスは、ワークロードまたはそのコンポーネントに向かう受信トラフィックです。イングレスをセキュリティで保護するのに役立つように、上記の一連の主要な戦略を適用します。トラフィックの送信元と、それが予想されたものか、許可されたものか、安全であるかを判断します。イングレスを確認したり、基本的なネットワークセキュリティ対策を実装したりしないと、パブリッククラウドプロバイダーの IP アドレス範囲をスキャンする攻撃者が防御の突破に成功する可能性があります。
エグレス。エグレスは、ワークロードまたはそのコンポーネントから出る送信トラフィックです。エグレスを確認するには、トラフィックの方向と、送信先が予想されたものか、許可されたものか、安全であるかを判断します。送信先は悪意があるか、データ流出リスクに関連する可能性があります。

また、パブリックインターネットへのワークロードの近接通信を考慮して、公開のレベルを判断することもできます。たとえば、通常、アプリケーションプラットフォームはパブリック IP アドレスを提供します。ワークロードコンポーネントはソリューションの顔です。

影響の範囲

南北。ワークロードネットワークと外部ネットワークの間を流れるトラフィックは、南北トラフィックです。このトラフィックは、ネットワークのエッジを通過します。外部ネットワークは、パブリックインターネット、企業ネットワーク、または制御の範囲外にあるその他のネットワークにすることができます。

イングレスとエグレスの両方を南北トラフィックにすることができます。

例として、ハブスポークネットワークトポロジのエグレスフローについて考えてみます。ハブが外部ネットワークになるように、ワークロードのネットワークエッジを定義できます。その場合、スポークの仮想ネットワークからの送信トラフィックは南北トラフィックです。ただし、制御範囲内のハブネットワークについて考える場合、次ホップはインターネットであり、敵対的である可能性があるため、南北トラフィックはハブ内のファイアウォールに拡張されます。
東西。ワークロードネットワーク内を流れるトラフィックは、東西トラフィックです。この種類のトラフィックは、ワークロード内のコンポーネントが相互に通信するときに発生します。たとえば、n 層アプリケーションの層間のトラフィックです。マイクロサービスでは、サービス間通信は東西トラフィックです。

多層防御を提供するには、各ホップに含まれるか、パケットが内部セグメントを通過するときに使用するセキュリティアフォーダンスのエンドツーエンドの制御を維持します。リスクレベルが異なると、異なるリスク修復方法が必要になります。

上の図は、プライベートクラウドでのネットワーク多層防御を示しています。この図では、パブリックおよびプライベート IP アドレス空間の境界は、パブリッククラウドの図よりもワークロードから大幅に離れています。複数のレイヤーによって、Azure デプロイがパブリック IP アドレス空間から分離されます。

Note

ID は常に主要な境界です。アクセス管理は、ネットワークフローに適用する必要があります。ネットワークのコンポーネント間で Azure ロールベースのアクセス制御 (RBAC) を使用する場合は、マネージド ID を使います。

フローを分類した後、セグメント化演習を実行して、ネットワークセグメントの通信パス上のファイアウォールインジェクションポイントを特定します。 すべてのセグメントとすべてのトラフィックの種類でネットワーク多層防御を設計する場合は、すべてのポイントで侵害を想定します。使用可能なすべての境界で、さまざまなローカライズされたネットワーク制御の組み合わせを使用します。詳細については、セグメント化戦略に関するページを参照してください。

エッジでファイアウォールを適用する

インターネットエッジトラフィックは南北トラフィックであり、それにはイングレスとエグレスが含まれます。脅威を検出またはブロックするには、エッジ戦略によってインターネットとの間で可能な限り多くの攻撃を軽減する必要があります。

エグレスについては、インターネットに向けたすべてのトラフィックを単一のファイアウォール経由で送信します。これにより、トラフィックの監視、ガバナンス、制御が強化されます。イングレスについては、インターネットからのすべてのトラフィックがネットワーク仮想アプライアンス (NVA) または Web アプリケーションファイアウォールを通過するように強制します。

ファイアウォールは通常、組織内のリージョンごとにデプロイされるシングルトンです。その結果、ワークロード間で共有され、中央チームによって所有されます。ワークロードのニーズをサポートするために、使用するすべての NVA が構成されていることを確認してください。
できるだけ Azure ネイティブ制御を使用することをお勧めします。

ネイティブ制御に加えて、高度な機能や特殊な機能を提供するパートナー NVA も検討できます。パートナーファイアウォールと Web アプリケーションファイアウォールベンダー製品は、Azure Marketplace で入手できます。

パートナーソリューションではなくネイティブ機能を使用する決定は、組織のエクスペリエンスと要件に基づく必要があります。

トレードオフ: 多くの場合、パートナー機能により、洗練された (ただし、通常は珍しい) 攻撃を防御できる高度な機能が提供されます。パートナーソリューションは、クラウドのファブリックコントローラーに統合されないため、その構成が複雑で脆弱である可能性があります。コストの観点からは、パートナーソリューションよりも安価であるため、、ネイティブ制御が推奨されます。

考慮する技術的なすべてのオプションで、イングレスとエグレスの両方のフローにセキュリティ制御と監視を提供する必要があります。 Azure で使用できるオプションについては、この記事の「エッジセキュリティ」セクションを参照してください。

仮想ネットワークとサブネットのセキュリティを設計する

プライベートクラウドの主な目的は、パブリックインターネットからリソースを隠すことです。この目標を達成するには、いくつかの方法があります。

プライベート IP アドレス空間に移動します。これは、仮想ネットワークを使用して実現できます。独自のプライベートネットワーク内でもネットワーク通信経路を最小限に抑えます。
使用するパブリック DNS エントリの数を最小限に抑え、公開するワークロードを少なくします。
イングレスおよびエグレスネットワークフロー制御を追加します。信頼されていないトラフィックは許可しないでください。

セグメント化戦略

ネットワークの可視性を最小限に抑えるには、ネットワークをセグメント化し、最小特権のネットワーク制御から始めます。セグメントがルーティングできない場合は、アクセスできません。ネットワークアクセスを介して相互に通信する必要があるセグメントのみを含むように範囲を広げます。

サブネットを作成して、仮想ネットワークをセグメント化できます。分割の基準は意図的である必要があります。サブネット内にサービスを併置する場合は、それらのサービスが相互に表示できることを確認します。

セグメント化は、多くの要因に基づいて行うことができます。たとえば、専用セグメントに異なるアプリケーション層を配置できます。もう 1 つのアプローチは、既知のプロトコルを使用する一般的なロールと機能に基づいてサブネットを計画することです。

詳細については、セグメント化戦略に関するページを参照してください。

サブネットファイアウォール

各サブネットの受信および送信トラフィックを調べることが重要です。この記事で前述した 3 つの主要な戦略を、「主要な設計戦略」で使用します。フローが予想されたものか、許可されたものか、安全であるかを確認します。この情報を確認するには、トラフィックのプロトコル、送信元、送信先に基づくファイアウォール規則を定義します。

Azure では、ネットワークセキュリティグループにファイアウォール規則を設定します。詳細については、この記事の「ネットワークセキュリティグループ」セクションを参照してください。

サブネット設計の例については、Azure Virtual Network サブネットに関するページを参照してください。

コンポーネントレベルで制御を使用する

ネットワークの可視性を最小限に抑えた後、ネットワークの観点から Azure リソースに関する計画を立て、フローを評価します。次の種類のフローを使用できます。

計画トラフィック、またはアーキテクチャ設計に従ったサービス間の意図的な通信。たとえば、アーキテクチャで Azure Functions が Azure Service Bus からメッセージをプルすることが推奨される場合のトラフィックを計画しています。
管理トラフィック、またはサービスの機能の一部として発生する通信。このトラフィックは設計の一部ではなく、制御できません。マネージドトラフィックの例として、アーキテクチャ内の Azure サービスと Azure 管理プレーンの間の通信があります。

計画トラフィックと管理トラフィックを区別すると、ローカライズされた、またはサービスレベルの制御を構築するのに役立ちます。各ホップの送信元と送信先を十分に理解してください。特に、データプレーンがどのように公開されているかを理解します。

開始点として、各サービスがインターネットに公開されているかどうかを判断します。そうである場合は、アクセスを制限する方法を計画します。そうでない場合は、仮想ネットワークに配置します。

サービスファイアウォール

サービスがインターネットに公開されると予想される場合は、ほとんどの Azure リソースで使用できるサービスレベルのファイアウォールを利用します。このファイアウォールを使用する場合は、アクセスパターンに基づいて規則を設定できます。詳細については、この記事の「Azure サービスファイアウォール」セクションを参照してください。

Note

コンポーネントがサービスでない場合は、ネットワークレベルのファイアウォールに加えて、ホストベースのファイアウォールを使用します。仮想マシン (VM) は、サービスではないコンポーネントの例です。

サービスとしてのプラットフォーム (PaaS) サービスへの接続

PaaS サービスへのアクセスをセキュリティで保護するのに役立つように、プライベートエンドポイントの使用を検討してください。プライベートエンドポイントには、仮想ネットワークからプライベート IP アドレスが割り当てられます。エンドポイントにより、ネットワーク内の他のリソースがプライベート IP アドレス経由で PaaS サービスと通信できるようになります。

PaaS サービスとの通信は、サービスのパブリック IP アドレスと DNS レコードを使用して実現されます。その通信はインターネット経由で行われます。その通信をプライベートにすることができます。

PaaS サービスからいずれかのサブネットへのトンネルによって、プライベートチャネルが作成されます。すべての通信は、コンポーネントのプライベート IP アドレスとそのサブネット内のプライベートエンドポイントの間で行われ、その後、PaaS サービスとの通信が行われます。

この例では、左側の画像は、パブリックに公開されたエンドポイントのフローを示しています。右側では、そのフローはプライベートエンドポイントを使用してセキュリティ保護されています。

詳細については、この記事の「プライベートエンドポイント」セクションをご覧ください。

Note

サービスファイアウォールと組み合わせてプライベートエンドポイントを使用することをお勧めします。サービスファイアウォールでは、受信インターネットトラフィックをブロックし、プライベートエンドポイントを使用する内部ユーザーにサービスをプライベートに公開します。

プライベートエンドポイントを使用するもう 1 つの利点は、送信トラフィック用にファイアウォール上のポートを開く必要がないことです。 プライベートエンドポイントでは、パブリックインターネットのポート上のすべての送信トラフィックをロックダウンします。 接続はネットワーク内のリソースに制限されます。

トレードオフ: Azure Private Link は有料サービスであり、処理される受信および送信データの測定があります。プライベートエンドポイントに対しても課金されます。

分散型サービス拒否 (DDoS) 攻撃から保護する

DDoS 攻撃では、アプリケーションのリソースを使い果たし、正当なユーザーがそのアプリケーションを使用できないようにしようとします。 DDoS 攻撃は、インターネット経由でパブリックに到達可能なすべてのエンドポイントをターゲットにすることができます。

DDoS 攻撃は、通常、システムのリソースの地理的に分散した大規模で広範囲にわたる悪用であり、送信元の特定とブロックが困難になります。

これらの攻撃からの保護に役立つ Azure サポートについては、この記事の「Azure DDoS Protection」セクションを参照してください。

Azure ファシリテーション

次の Azure サービスを使用して、多層防御機能をネットワークに追加できます。

Azure Virtual Network

仮想ネットワークは、Azure リソースで、相互に、およびインターネットやオンプレミスネットワークと、安全に通信するのに役立ちます。

既定では、仮想ネットワーク内のすべてのリソースがインターネットとの送信通信に関与できます。しかし、受信通信は既定で制限されます。

Virtual Network には、トラフィックをフィルター処理するための機能が用意されています。ユーザー定義ルート (UDR) とファイアウォールコンポーネントを使用して、仮想ネットワークレベルでアクセスを制限できます。サブネットレベルでは、ネットワークセキュリティグループを使用してトラフィックをフィルター処理できます。

エッジセキュリティ

既定では、イングレスとエグレスの両方がパブリック IP アドレスを経由します。サービスまたはトポロジに応じて、これらのアドレスを設定するか、Azure で割り当てます。その他の考えられるイングレスとエグレスには、ロードバランサーまたはネットワークアドレス変換 (NAT) ゲートウェイを介したトラフィックの受け渡しが含まれます。しかし、これらのサービスはトラフィックの分散を目的としており、必ずしもセキュリティを目的としたものではありません。

次のテクノロジの選択肢が推奨されます。

Azure Firewall。 Azure Firewall は、ネットワークエッジと、ハブスポークネットワークや仮想 WAN などの一般的なネットワークトポロジで使用できます。通常は、トラフィックがインターネットに送信される前に最終的なセキュリティゲートとして機能するエグレスファイアウォールとして Azure Firewall をデプロイします Azure Firewall では、リモートデスクトッププロトコル (RDP)、Secure Shell Protocol (SSH)、ファイル転送プロトコル (FTP) など、HTTP 以外と HTTPS 以外のプロトコルを使用するトラフィックをルーティングできます。 Azure Firewall の機能セットには、次のものが含まれます。
- 宛先ネットワークアドレス変換 (DNAT)、またはポート転送。
- 侵入検出および防止システム (IDPS) シグネチャ検出。
- 強力なレイヤー 3、レイヤー 4、完全修飾ドメイン名 (FQDN) ネットワーク規則。
Note

ほとんどの組織には、NVA を通過するようにトラフィックを強制する強制トンネリングポリシーがあります。

仮想 WAN トポロジを使用しない場合は、NVA のプライベート IP アドレスに NextHopType が Internet の UDR をデプロイする必要があります。 UDR はサブネットレベルで適用されます。既定では、サブネット間トラフィックは NVA を通過しません。

イングレスに Azure Firewall を同時に使用することもできます。 HTTP および HTTPS トラフィックをルーティングできます。上位階層 SKU では、ペイロードレベルの検査を実装できるように、Azure Firewall によって TLS 終端が提供されます。

次のプラクティスが推奨されます。
- Azure Firewall で診断設定を有効にして、トラフィックフローログ、IDPS ログ、DNS 要求ログを収集します。
- 規則でできるだけ具体的にします。
- 実用的な場合は、FQDN サービスタグの使用は避けます。ただし、それらを使用する場合は、リージョンバリアントを使います。これにより、サービスのすべてのエンドポイントとの通信が可能になります。
- IP グループを使用して、IP グループの有効期間にわたって同じ規則を共有する必要がある送信元を定義します。 IP グループには、セグメント化戦略が反映されている必要があります。
- ワークロードで絶対エグレス制御が必要な場合にのみ、インフラストラクチャの FQDN 許可規則をオーバーライドします。この規則をオーバーライドすると、サービスの Azure プラットフォーム要件が変わるため、信頼性のトレードオフが伴います。
トレードオフ: Azure Firewall はパフォーマンスに影響を与える可能性があります。規則の順序、数量、TLS 検査などの要因により、大幅な待機時間が発生する可能性があります。

ワークロードの信頼性にも影響を与える可能性があります。送信元ネットワークアドレス変換 (SNAT) ポートの枯渇が発生する可能性があります。この問題の解決に役立つように、必要に応じてパブリック IP アドレスを追加します。

リスク: エグレストラフィックの場合、Azure によってパブリック IP アドレスが割り当てられます。この割り当ては、外部セキュリティゲートにダウンストリームの影響を与える可能性があります。
Azure Web Application Firewall。このサービスでは受信フィルター処理をサポートし、HTTP および HTTPS トラフィックのみが対象となります。

Open Worldwide Application Security Project (OWASP) が OWASP Top 10 ドキュメントで特定する脅威など、一般的な攻撃に対する基本的なセキュリティが提供されます。 Azure Web Application Firewall には、レート制限、SQL インジェクション規則、クロスサイトスクリプティングなど、レイヤー 7 に重点を置いたその他のセキュリティ機能も用意されています。

Azure Web Application Firewall では、ほとんどのチェックはペイロードに基づいているため、TLS 終端が必要です。

Azure Web Application Firewall は、Azure Application Gateway や Azure Front Door などのルーターと統合できます。このような種類のルーターに対する Azure Web Application Firewall の実装は異なる場合があります。

Azure Firewall と Azure Web Application Firewall は、相互に排他的な選択肢ではありません。エッジセキュリティソリューションでは、さまざまなオプションを使用できます。例については、「仮想ネットワークのファイアウォールと Application Gateway」を参照してください

ネットワークセキュリティグループ

ネットワークセキュリティグループは、サブネットまたはネットワークインターフェイスカード (NIC) レベルで適用するレイヤー 3 およびレイヤー 4 のファイアウォールです。ネットワークセキュリティグループは、既定では作成も適用もされません。

サブネットの境界で送受信されるトラフィックを停止するためのファイアウォールとして、ネットワークセキュリティグループの規則が機能します。ネットワークセキュリティグループには、過度に制限の少ない既定の規則セットがあります。たとえば、既定の規則では、エグレスの観点からファイアウォールは設定されません。イングレスの場合、受信インターネットトラフィックは許可されません。

規則を作成するには、既定の規則セットから開始します。

送信トラフィック、またはイングレスの場合:
- 直接、ピアリング、VPN ゲートウェイの送信元からの仮想ネットワークトラフィックが許可されます。
- Azure Load Balancer の正常性プローブは許可されます。
- その他のトラフィックはすべてブロックされます。
送信トラフィック、またはエグレスの場合:
- 直接、ピアリング、VPN ゲートウェイの送信先への仮想ネットワークトラフィックが許可されます。
- インターネットへのトラフィックが許可されます。
- その他のトラフィックはすべてブロックされます。

次に、以下の 5 つの要因を考慮します。

Protocol
ソース IP アドレス
送信元ポート
宛先 IP アドレス
宛先ポート

FQDN のサポートがないため、ネットワークセキュリティグループの機能が制限されます。ワークロードに特定の IP アドレス範囲を指定する必要があり、管理が困難です。

しかし、Azure サービスの場合は、サービスタグを使用して、送信元と送信先の IP アドレス範囲を要約できます。サービスタグのセキュリティ上の利点は、ユーザーに不透明であり、その責任が Azure にオフロードされていることです。また、トラフィックのルーティング先の種類としてアプリケーションセキュリティグループを割り当てることもできます。この種類の名前付きグループには、受信または送信アクセスのニーズが似ているリソースが含まれています。

リスク: サービスタグの範囲は非常に広いので、可能な限り幅広い顧客に対応できます。サービスの変更に対してサービスタグの更新が遅れます。

上の図では、ネットワークセキュリティグループが NIC に適用されています。インターネットトラフィックとサブネット間トラフィックは拒否されます。ネットワークセキュリティグループは、VirtualNetwork タグと共に適用されます。そのため、この場合、ピアリングされたネットワークのサブネットには直接の通信経路があります。 VirtualNetwork タグの広範な定義は、セキュリティに大きな影響を与える可能性があります。

サービスタグを使用するときは、可能な場合は、Storage ではなく、Storage.WestUS などのリージョンバージョンを使います。このアプローチを使用すると、特定のリージョン内のすべてのエンドポイントにスコープを制限できます。

一部のタグは、受信または送信トラフィック専用です。その他は "両方" の種類用です。受信タグを使用すると、通常、AzureFrontDoor.Backend などのすべてのホスティングワークロードからのトラフィックや、LogicAppsManagement などのサービスランタイムをサポートする Azure からのトラフィックが許可されます。同様に、送信タグを使用すると、すべてのホスティングワークロードへのトラフィック、またはサービスランタイムをサポートする Azure からのトラフィックが許可されます。

可能な限り規則の範囲を設定します。次の例では、規則は特定の値に設定されています。その他の種類のトラフィックは拒否されます。

情報	例
Protocol	伝送制御プロトコル (TCP)、UDP
送信元 IP アドレス	<source-IP-address-range> からサブネットへのイングレスを許可する: 4575/UDP
ソースポート	<service-tag> からのサブネットへのイングレスを許可する: 443/TCP
宛先 IP アドレス	サブネットから <destination-IP-address-range> へのエグレスを許可する: 443/TCP
宛先ポート	サブネットから <service-tag> へのエグレスを許可する: 443/TCP

まとめると次のようになります。

規則を作成するときは正確に。アプリケーションが機能するために必要なトラフィックのみを許可します。その他すべては拒否します。このアプローチでは、ネットワーク通信経路を、ワークロードの操作をサポートするために必要なネットワークフローに制限します。 必要以上に多くのネットワークフローをサポートすると、不要な攻撃ベクトルが発生し、攻撃可能領域が拡張されます。

トラフィックを制限しても、許可されたフローが攻撃の範囲を超えるわけではありません。ネットワークセキュリティグループは、開放型システム間相互接続 (OSI) スタックのレイヤー 3 と 4 で動作するため、形状と方向の情報のみが含まれます。たとえば、ワークロードでインターネットへの DNS トラフィックを許可する必要がある場合は、Internet:53:UDP のネットワークセキュリティグループを使用します。この場合、攻撃者はポート 53 上の UDP 経由で他のサービスにデータを流出させることができる可能性があります。
ネットワークセキュリティグループは、互いに若干異なる場合があることを理解してください。違いの意図を見落としがちです。 細かいフィルター処理を行う場合は、追加のネットワークセキュリティグループを作成する方が安全です。 少なくとも 1 つのネットワークセキュリティグループを設定します。
- ネットワークセキュリティグループを追加すると、フローログやネットワークトラフィック分析など、多くの診断ツールのロックが解除されます。
- Azure Policy を使用すると、ネットワークセキュリティグループのないサブネット内のトラフィックの制御に役立ちます。
サブネットでネットワークセキュリティグループがサポートされている場合、影響が最小限であっても、グループを追加してください。

Azure サービスファイアウォール

ほとんどの Azure サービスにより、サービスレベルのファイアウォールが提供されています。この機能では、指定されたクラスレスドメイン間ルーティング (CIDR) 範囲からサービスへのイングレストラフィックを検査します。これらのファイアウォールには、次の利点があります。

基本レベルのセキュリティが提供されます。
許容できるパフォーマンスへの影響があります。
ほとんどのサービスにより、これらのファイアウォールが追加料金なしで提供されます。
ファイアウォールでは Azure Diagnostics を介してログを出力します。これは、アクセスパターンの分析に役立ちます。

しかし、これらのファイアウォールに関するセキュリティ上の懸念事項もあり、パラメーターの指定に関する制限があります。たとえば、Microsoft がホストするビルドエージェントを使用する場合は、Microsoft がホストするすべてのビルドエージェントの IP アドレス範囲を開く必要があります。その後、この範囲は、ビルドエージェント、他のテナント、敵対者 (サービスを悪用する可能性のある) に対して開かれます。

サービスのアクセスパターンがあり、サービスファイアウォール規則セットとして構成できる場合は、そのサービスを有効にする必要があります。 Azure Policy を使用して有効にすることができます。既定で有効になっていない場合は、信頼できる Azure サービスオプションを有効にしないようにしてください。そのようにすると、規則の範囲内にあるすべての依存サービスが取り込まれます。

詳細については、個々の Azure サービスの製品ドキュメントを参照してください。

プライベートエンドポイント

Private Link によって、PaaS インスタンスにプライベート IP アドレスを付与する方法が提供されます。その後、サービスにはインターネット経由で到達できません。プライベートエンドポイントは、すべての SKU でサポートされているわけではありません。

プライベートエンドポイントを使用する場合は、次の推奨事項に留意してください。

PaaS サービスでパブリックアクセスを提供する必要がある場合でも、プライベートエンドポイントを介して PaaS サービスに接続するように、仮想ネットワークにバインドされているサービスを構成します。
プライベートエンドポイント IP アドレスへのアクセスを制限するために、プライベートエンドポイントのネットワークセキュリティグループの使用を促進します。
プライベートエンドポイントを使用する場合は、常にサービスファイアウォールを使用します。
可能であれば、プライベートエンドポイント経由でのみアクセスできるサービスがある場合は、そのパブリックエンドポイントの DNS 構成を削除します。
プライベートエンドポイントを実装する際には、実行時の通信経路に関する懸念事項を考慮してください。しかし、DevOps と監視に関する懸念事項も考慮してください。
Azure Policy を使用して、リソース構成を適用します。

トレードオフ: プライベートエンドポイントを持つサービス SKU はコストがかかります。プライベートエンドポイントは、ネットワークのあいまいさのために操作を複雑にする可能性があります。セルフホステッドエージェント、ジャンプボックス、VPN、およびその他のコンポーネントをアーキテクチャに追加する必要があります。

DNS 管理は、一般的なネットワークトポロジでは複雑になる可能性があります。 DNS フォワーダーやその他のコンポーネントを導入する必要がある場合があります。

仮想ネットワークインジェクション

仮想ネットワークインジェクションプロセスを使用して、一部の Azure サービスをネットワークにデプロイできます。このようなサービスの例としては、Azure App Service、Functions、Azure API Management、Azure Spring Apps などがあります。このプロセスにより、インターネット、プライベートネットワーク内のシステム、他の Azure サービスからアプリケーションが分離されます。アプリケーションからの受信トラフィックと送信トラフィックは、ネットワーク規則に基づいて許可または拒否されます。

Azure Bastion

Azure Bastion を使用し、ブラウザーと Azure portal を使って VM に接続できます。 Azure Bastion により、RDP および SSH 接続のセキュリティが強化されます。一般的なユースケースには、同じ仮想ネットワークまたはピアリングされた仮想ネットワーク内のジャンプボックスへの接続が含まれます。 Azure Bastion を使用すると、VM にパブリック IP アドレスを設定する必要がなくなります。

Azure DDoS Protection

Azure 内のすべてのプロパティは、追加コストなしで、構成を追加することなく、Azure DDoS インフラストラクチャ保護によって保護されます。保護のレベルは基本ですが、保護のしきい値は高くなります。また、テレメトリやアラートも提供されず、ワークロードに依存しません。

DDoS Protection の上位階層 SKU は利用できますが、無料ではありません。グローバルにデプロイされた Azure ネットワークのスケールと容量により、一般的なネットワーク層攻撃に対する保護が提供されます。この機能は、常時接続トラフィック監視やリアルタイム軽減策などのテクノロジによって提供されます。

詳細については、Azure DDoS Protection の概要に関する記事を参照してください。

例

この記事で推奨されるネットワーク制御の使用例をいくつか以下に示します。

IT 環境

この例は、セキュリティベースライン (SE:01) で確立された情報技術 (IT) 環境を基にしています。このアプローチでは、トラフィックを制限するためにさまざまな境界で適用されるネットワーク制御を幅広く理解できます。

ネットワーク攻撃ペルソナ。ネットワーク攻撃では、管理者、従業員、顧客のクライアント、匿名の攻撃者など、いくつかのペルソナが考慮される可能性があります。
VPN アクセス。悪意のあるアクターは、VPN 経由でオンプレミス環境にアクセスしたり、VPN 経由でオンプレミス環境に接続されている Azure 環境にアクセスしたりする可能性があります。セキュリティで保護された通信を有効にするように IPSec プロトコルを使用して構成します。
アプリケーションへのパブリックアクセス。ネットワーク OSI レイヤーのレイヤー 7 で保護するために、アプリケーションの前に Web アプリケーションファイアウォール (WAF) を設定します。
オペレーターアクセス。ネットワーク OSI レイヤーのレイヤー 4 を介したリモートアクセスをセキュリティで保護する必要があります。 IDP/IDS 機能で Azure Firewall を使用することを検討してください。
DDoS 保護。 VNet 全体に対して DDoS 保護を行います。
ネットワークトポロジ。ハブスポークなどのネットワークトポロジは、より安全であり、コストを最適化します。ハブネットワークによって、すべてのピアリングされたスポークに一元的なファイアウォール保護が提供されます。
プライベートエンドポイント: プライベートエンドポイントを使用して、パブリックに公開されたサービスをプライベートネットワークに追加することを検討してください。これにより、プライベート VNet にネットワークカード (NIC) が作成され、Azure サービスにバインドされます。
TLS 通信。 TLS 経由で通信して転送中のデータを保護します。
ネットワークセキュリティグループ (NSG): NSG を使用して VNet 内のセグメントを保護します。これは、IP とポートの範囲を考慮して TCP/UDP の受信および送信通信をフィルター処理する無料のリソースです。 NSG の一部は、管理を容易にするためにトラフィック規則のタグを作成できるアプリケーションセキュリティグループ (ASG) です。
Log Analytics。 Azure リソースによって、Log Analytics に取り込まれたテレメトリが出力され、分析のために Microsoft Sentinel などの SIEM ソリューションと共に使用されます。
Microsoft Sentinel の統合。 Log Analytics は、Microsoft Sentinel や Microsoft Defender for Cloud などの他のソリューションと統合されています。
Microsoft Defender for Cloud。 Microsoft Defender for Cloud により、環境に関するネットワークの推奨事項を含め、多くのワークロード保護ソリューションが提供されています。
Traffic Analytics: Traffic Analytics を使用してネットワーク制御を監視します。これは、Azure Monitor の一部である Network Watcher を介して構成され、NSG によって収集されたサブネットの受信および送信ヒットを集計します。

コンテナー化されたワークロードのアーキテクチャ

このアーキテクチャ例では、この記事で説明されているネットワーク制御を組み合わせています。この例では、完全なアーキテクチャは示されていません。代わりに、プライベートクラウドでのイングレス制御に重点が置かれています。

Application Gateway は Web トラフィックロードバランサーであり、Web アプリケーションへのトラフィック管理に使用できます。 Application Gateway は、ネットワークセキュリティグループ制御と Web アプリケーションファイアウォール制御が配置された専用サブネットにデプロイします。

すべての PaaS サービスとの通信は、プライベートエンドポイントを介して行われます。すべてのエンドポイントは専用サブネットに配置されます。 DDoS Protection は、基本レベル以上のファイアウォール保護用に構成されているすべてのパブリック IP アドレスを保護するのに役立ちます。

管理トラフィックは Azure Bastion を介して制限されます。これは、TLS 経由で Azure portal から直接 VM に、セキュリティで保護されたシームレスな RDP および SSH 接続を提供するのに役立ちます。ビルドエージェントは、コンピューティングリソース、コンテナーレジストリ、データベースなどのワークロードリソースに対するネットワークビューを持つように、仮想ネットワークに配置されます。このアプローチは、ビルドエージェントのセキュリティで保護された分離環境を提供するのに役立ちます。これにより、コードと成果物の保護が強化されます。

コンピューティングリソースのサブネットレベルのネットワークセキュリティグループにより、エグレストラフィックが制限されます。強制トンネリングは、すべてのトラフィックを Azure Firewall 経由でルーティングするために使用されます。このアプローチは、コンピューティングリソースのセキュリティで保護された分離環境を提供するのに役立ちます。これにより、データとアプリケーションの保護が強化されます。

セキュリティチェックリスト

レコメンデーションの完全なセットを参照してください。

セキュリティチェックリスト

次の方法で共有

ネットワークと接続に関する推奨事項