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

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

この Azure Well-Architected Framework セキュリティチェックリストの推奨事項に適用されます。

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

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

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

定義

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

主要な設計戦略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トラフィックの方向

イングレス。イングレスは、ワークロードまたはそのコンポーネントに向かって流れる受信トラフィックです。イングレスをセキュリティで保護するには、上記の一連の主要な戦略を適用します。トラフィックソースが何であるか、およびトラフィックソースが予想、許可、および安全かどうかを判断します。パブリッククラウドプロバイダーの IP アドレス範囲をスキャンする攻撃者は、イングレスをチェックしたり、基本的なネットワークセキュリティ対策を実装したりしないと、防御に正常に侵入する可能性があります。
エグレス。エグレスは、ワークロードまたはそのコンポーネントから流出する送信トラフィックです。エグレスをチェックするには、トラフィックの送信先と、宛先が想定、許可、および安全かどうかを判断します。宛先が悪意のあるものであるか、データ流出リスクに関連付けられている可能性があります。

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

影響範囲

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

イングレスとエグレスは、どちらも南北トラフィックにすることができます。

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

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

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

注意

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

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

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

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

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

ファイアウォールは通常、organization内のリージョンごとにデプロイされるシングルトンです。その結果、ワークロード間で共有され、中央チームが所有します。使用する NVA が、ワークロードのニーズをサポートするように構成されていることを確認します。
可能な限り Azure ネイティブコントロールを使用することをお勧めします。

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

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

トレードオフ: パートナーの機能は、高度な攻撃から保護できる高度な機能を提供することがよくありますが、通常は一般的ではありません。これらのソリューションはクラウドのファブリックコントローラーと統合されないため、パートナーソリューションの構成は複雑で脆弱になる可能性があります。コストの観点から見ると、パートナーソリューションよりもコストが安いため、ネイティブコントロールが推奨されます。

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

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

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

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

セグメント化戦略

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

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

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

詳細については、「セグメント化戦略」を参照してください。

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

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

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

サブネット設計の例については、「Azure Virtual Network サブネット」を参照してください。

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

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

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

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

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

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

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

注意

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

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

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

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

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

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

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

注意

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

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

トレードオフ: Azure Private Linkは、処理される受信データと送信データのメーターを含む有料サービスです。プライベートエンドポイントにも課金されます。

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

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

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

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

Azure ファシリテーション

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

Azure Virtual Network

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

既定では、仮想ネットワーク内のすべてのリソースがインターネットとの送信通信を行うことができます。ただし、受信通信は既定で制限されています。

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

Edge セキュリティ

既定では、イングレスとエグレスの両方がパブリック 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) ネットワーク規則。
注意

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

仮想 WAN トポロジを使用しない場合は、の UDRNextHopTypeInternet を NVA のプライベート IP アドレスにデプロイする必要があります。 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.WestUS リージョンバージョンを Storage使用します。この方法を使用すると、特定のリージョン内のすべてのエンドポイントにスコープを制限できます。

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

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

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

まとめ

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

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

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

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

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

ただし、これらのファイアウォールに関連するセキュリティ上の問題もあり、パラメーターの指定には制限があります。たとえば、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経由でルーティングするために使用されます。このアプローチは、コンピューティングリソースのセキュリティで保護された分離された環境を提供するのに役立ちます。これにより、データとアプリケーションの保護が強化されます。

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

推奨事項の完全なセットを参照してください。

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

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