次の方法で共有


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

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

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

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

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

定義

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

主要な設計戦略

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

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

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

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

    仮想ネットワーク内の分割されたサブネットなど、他の論理境界を使用することもできます。 サブネットの利点は、サブネットを使用して、分離境界内にあり、同様のセキュリティ保証を持つリソースをグループ化できることです。 その後、トラフィックをフィルター処理するように境界上のコントロールを構成できます。

  • フィルター。 この戦略は、 境界に入るトラフィックが期待、許可、および安全であることを確認するのに役立ちます。 Zero-Trust の観点から、フィルター処理では、ネットワーク レベルで使用可能なすべてのデータ ポイントが明示的に検証されます。 境界にルールを配置して、特定の条件にチェックできます。

    たとえば、ヘッダー レベルでは、トラフィックが予想される場所から発信されているか、予想されるボリュームを持っていることを規則で確認できます。 しかし、これらのチェックでは十分ではありません。 トラフィックが予想される特性を示していても、ペイロードが安全でない可能性があります。 検証チェックにより、SQL インジェクション攻撃が発生する可能性があります。

  • 変換セキュリティ対策として、境界のパケットを変更します。 たとえば、HTTP ヘッダーを削除して、公開のリスクを排除できます。 または、ある時点でトランスポート層セキュリティ (TLS) をオフにし、より厳密に管理されている証明書を使用して別のホップで再確立することもできます。

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

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

  • ワークロードが外部ネットワークと通信する必要がある場合、それらのネットワークに必要な近接レベルは何である必要がありますか?

  • 予想されるプロトコルやパケットのソースと形状など、フローのネットワーク特性は何ですか? ネットワーク レベルでコンプライアンス要件はありますか?

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

外部ネットワークからの可視性
  • パブリック。 ワークロードとその他のコンポーネントがパブリック インターネットから到達可能な場合、ワークロードはパブリックに公開されます。 アプリケーションは、1 つ以上のパブリック IP アドレスとパブリック ドメイン ネーム システム (DNS) サーバーを介して公開されます。

  • プライベート。 ワークロードは、仮想プライベート ネットワーク (VPN) などのプライベート ネットワーク経由でのみアクセスできる場合はプライベートです。 これは、1 つ以上のプライベート IP アドレスを介してのみ公開され、プライベート DNS サーバーを介して公開される可能性があります。

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

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

トラフィックの方向

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

  • エグレス。 エグレスは、ワークロードまたはそのコンポーネントから流出する送信トラフィックです。 エグレスをチェックするには、トラフィックの送信先と、宛先が想定、許可、および安全かどうかを判断します。 宛先が悪意のあるものであるか、データ流出リスクに関連付けられている可能性があります。

Azure デプロイとインターネットの間のネットワーク トラフィック フローのフローを示す図。

また、 ワークロードがパブリック インターネットに近いことを考慮して、公開のレベルを決定することもできます。 たとえば、通常、アプリケーション プラットフォームはパブリック 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) 環境に基づいています。 このアプローチでは、トラフィックを制限するためにさまざまな境界で適用されるネットワーク制御を幅広く理解できます。

ネットワーク制御を使用したorganizationのセキュリティ ベースラインの例を示す図。

  1. ネットワーク攻撃ペルソナ。 管理者、従業員、顧客のクライアント、匿名の攻撃者など、ネットワーク攻撃ではいくつかのペルソナが考慮される可能性があります。

  2. VPN アクセス。 不適切なアクターは、VPN または VPN を介してオンプレミス環境に接続されている Azure 環境を介してオンプレミス環境にアクセスする可能性があります。 IPSec プロトコルを使用して構成し、セキュリティで保護された通信を有効にします。

  3. アプリケーションへのパブリック アクセス。 ネットワーク OSI レイヤーのレイヤー 7 で保護するために、アプリケーションの前に Web アプリケーション ファイアウォール (WAF) を用意します。

  4. オペレーター アクセス。 ネットワーク OSI レイヤーのレイヤー 4 を介したリモート アクセスをセキュリティで保護する必要があります。 IDP/IDS 機能でAzure Firewallを使用することを検討してください。

  5. DDoS 保護。 VNet 全体に対して DDoS 保護を持つ。

  6. ネットワーク トポロジ。 ハブスポークなどのネットワーク トポロジは、より安全で、コストを最適化します。 ハブ ネットワークは、ピアリングされたすべてのスポークに一元的なファイアウォール保護を提供します。

  7. プライベート エンドポイント: プライベート エンドポイントを使用して、パブリックに公開されたサービスをプライベート ネットワークに追加することを検討してください。 これにより、プライベート VNet にネットワーク カード (NIC) が作成され、Azure サービスにバインドされます。

  8. TLS 通信。 TLS 経由で通信することで、転送中のデータを保護します。

  9. ネットワーク セキュリティ グループ (NSG): NSG を使用して VNet 内のセグメントを保護します。これは、IP とポートの範囲を考慮して TCP/UDP の受信および送信通信をフィルター処理する無料のリソースです。 NSG の一部は、管理を容易にするためにトラフィック ルールのタグを作成できるアプリケーション セキュリティ グループ (ASG) です。

  10. Log Analytics。 Azure リソースは、Log Analytics に取り込まれたテレメトリを出力し、分析のために Microsoft Sentinel などの SIEM ソリューションと共に使用します。

  11. Microsoft Sentinel 統合。 Log Analytics は、Microsoft Sentinel やその他のソリューション (Microsoft Defender for Cloud など) と統合されています。

  12. Microsoft Defender for Cloud。 Microsoft Defender for Cloud には、環境のネットワークに関する推奨事項など、多くのワークロード保護ソリューションが用意されています。

  13. Traffic Analytics: Traffic Analytics を使用してネットワーク制御を監視します。 これは、Azure Monitor の一部であるNetwork Watcherを使用して構成され、NSG によって収集されたサブネットの受信ヒットと送信ヒットを集計します。

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

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

Application Gateway、ネットワーク セキュリティ グループ、Azure Bastion、Azure DDoS Protection などの制御されたイングレスを示す図。

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

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

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

ネットワーク セキュリティ グループとAzure Firewallの制御されたエグレスを示す図。

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

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

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