次の方法で共有


Azure 上の Red Hat Enterprise Linux におけるネットワーク トポロジと接続性に関する考慮事項

この記事では、ネットワーク トポロジと接続性のための Azure ランディング ゾーン設計領域に関するガイダンスに基づいて、Red Hat Enterprise Linux (RHEL) ネットワークに関する考慮事項と推奨事項について説明します。

Architecture

次の RHEL アーキテクチャは初期設計であり、特定のビジネス要件と技術要件に合わせてさらに調整できます。 必要に応じて、冗長性を備える特定サイズの仮想マシン (VM) に、さまざまな RHEL プラットフォーム コンポーネントとロールをデプロイできます。 これらの例の簡素化されたネットワーク レイアウトは、アーキテクチャの原則を示しており、企業ネットワーク全体を網羅するものでありません。

RHEL の参照アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

要素 説明
A Microsoft 顧客契約および請求のコンポーネント
B Microsoft Entra ID およびアクセス管理のコンポーネント
C Azure 管理グループのコンポーネント
D Windows Server Active Directory ID 管理サブスクリプションのコンポーネント
E ネットワーク ハブ サブスクリプションのコンポーネント
F RHEL 管理および ID サブスクリプションのコンポーネント
G Azure 管理グループ サブスクリプションのコンポーネント
H RHEL 運用ワークロード サブスクリプションのコンポーネント
I オンプレミスのコンポーネント
J Red Hat クラウド サービス

RHEL ランディング ゾーン ネットワークに関する設計上の考慮事項

ランディング ゾーン ネットワークの設計に関する次の推奨事項を考慮します。

  • 単一リージョンまたはマルチリージョンのデプロイには、ハブスポーク ネットワーク トポロジを使用します。 Azure Virtual WAN ハブは追加の機能を提供しますが、従来の仮想ネットワーク ハブを使用することもできます。 詳細については、「Azure ランディング ゾーン ネットワーク」を参照してください。

  • Infrastructure as Code を使用して、すべてのランディング ゾーン ネットワーク関連コンポーネントのデプロイ、構成管理、Day-2 オペレーションを自動化します。

  • サポートされているすべての Azure サービスにプライベート エンドポイントを使用して、セキュリティを向上させます。 プライベート エンドポイントを使用すると、すべてのトラフィックがパブリック IP アドレスではなく、プライベート ネットワークを経由してルーティングされます。

ファイアウォールの考慮事項

次の図は、ハイブリッド Azure リージョン RHEL ランディング ゾーン アーキテクチャを示しています。

ハイブリッド Azure リージョン RHEL ランディング ゾーン アーキテクチャを示す図。

要素 説明
A Red Hat Management サブスクリプションを通じて含まれる Red Hat Management 仮想ネットワーク内のコンポーネント
B RHEL Production Workloads サブスクリプションを通じて含まれる RHEL ワークロード仮想ネットワーク内のコンポーネント
C Red Hat Identity Management サブスクリプションを通じて含まれる ID 管理仮想ネットワーク内のコンポーネント
D RHEL Production Workloads サブスクリプションを通じて含まれる RHEL ワークロード仮想ネットワーク内のコンポーネント
  • Virtual WAN トポロジの場合、ランディング ゾーン間のトラフィックをルーティングするために Azure Firewall の使用を考慮してください。 Azure Firewall はトラフィックのフィルター処理とログの機能を提供します。

  • Azure VPN ゲートウェイまたは Azure ExpressRoute ゲートウェイがハブへのハイブリッド接続を制御します。 トラフィックを監視および制御するには、ハブで Azure Firewall または仮想ネットワーク アプライアンス (NVA) を使用します。

  • オンプレミスのファイアウォールを使用して、すべてのイングレスとエグレスのインターネット トラフィックを保護およびルーティングできます。 ファイアウォールによりクラウドベースのリソースで遅延が発生する可能性があります。 パフォーマンスとセキュリティの要件を理解して、イングレスとエグレスのトラフィックをルーティングする方法を決定します。

サブネットに関する考慮事項

次の図は、ゾーン回復性のある構成における管理サブネットとワークロード サブネットを示しています。

ゾーン回復性のある構成における管理サブネットとワークロード サブネットを示す図。

  • RHEL ランディング ゾーンの IP アドレス範囲と仮想ネットワーク サイズを計画する際は、アプリケーション、データベース、ストレージ リソース専用のサブネットを考慮します。

  • 境界ネットワークとトラフィック セキュリティにゼロ トラストベースのアプローチを採用します。 詳細については、「Azure に対するネットワーク セキュリティ戦略」に関するページをご覧ください。

ネットワーク セキュリティ グループに関する考慮事項

トラフィック セキュリティの NSG 構成を示す図。

  • ネットワーク セキュリティ グループ (NSG) を使用して、サブネット間のトラフィックおよびプラットフォーム全体の east-west トラフィック (ランディング ゾーン間のトラフィック) を保護します。 Azure Policy を使用すると、この構成をすべてのサブネットの既定にすることができます。

  • NSG とアプリケーション セキュリティ グループによりランディング ゾーン内のトラフィックをマイクロセグメント化し、中央の NVA を使用してトラフィック フローをフィルター処理しないようにします。

  • NSG フロー ログを有効にして、トラフィック分析にフィードされるようにします。 監査機能とセキュリティを最適化するために、サブスクリプション内のすべての重要な仮想ネットワークとサブネットでフロー ログを有効にします。

  • ランディング ゾーン間の接続を選択的に許可するには、NSG を使用します。

  • アプリケーション チームは、サブネット レベルの NSG でアプリケーション セキュリティ グループを使用して、ランディング ゾーン内の多層 VM を保護する必要があります。

  • 組織でオンプレミス ロケーションへの強制トンネリングまたはアドバタイズされた既定のルートを実装している場合は、アウトバウンド NSG 規則を組み込んで、仮想ネットワークからインターネットへのエグレス トラフィックを直接拒否することを考慮します。 この構成により、Border Gateway Protocol (BGP) セッションがドロップした場合の回復性を得られます。 詳細については、「ランディング ゾーン ネットワークのセグメント化の計画」を参照してください。

その他の考慮事項

  • インターネットを有効にして、トラフィックのフィルター処理と検査を行います。 インターネットを有効にし、トラフィックをフィルター処理して検査するための送信オプションは次のとおりです。

    • ハブ ネットワークを介した Red Hat クラウドへの送信アクセス。
    • オンプレミスのインターネット アクセスを使用したオンプレミスの既定のルート。
    • Azure Firewall または NVA で保護された Virtual WAN または従来の仮想ネットワーク ハブ。
  • コンテンツとアプリケーションを配信します。 コンテンツとアプリケーションを配信するための受信オプションは次のとおりです。

    • L7、Transport Layer Security (TLS) 終端、Web Application Firewall を備えた Azure Application Gateway。
    • オンプレミスからの Dynamic Network Translation (DNAT) とロード バランサー。
    • Azure Firewall または NVA を使用した Azure Virtual Network、およびさまざまなシナリオでの Azure Route Server。
    • Azure Firewall、L4、DNAT を備えた Virtual WAN ハブ。
    • さまざまなシナリオでの NVA を使用した Virtual WAN ハブ。
  • オンプレミス リソースと Azure リソースのドメイン名解決を構成します。 RHEL 環境では、オンプレミス リソースと Azure リソースの両方を使用することが多く、リソースの効果的な名前解決が必要です。 次のレコメンデーションを検討してください:

    • Azure では、仮想ネットワーク内で既定の内部名前解決を利用できます。 このシナリオでは、構成は必要ありません。 ドメイン名解決サフィックスの変更や手動登録はできません。 詳細については、「Azure で提供されている名前解決」を参照してください。
    • 仮想ネットワーク間の名前解決には、RHEL デプロイでは多くの場合、Redhat Identity Management Server (IdM) または Azure DNS のドメイン ネーム システム (DNS) サービスを使用します。 規則ベースの転送を提供するには、Azure Private DNS Resolver と既存の DNS インフラストラクチャを組み合わせます。

次のステップ