ネットワーク制御を使用したミッション クリティカルなベースライン アーキテクチャ
このアーキテクチャでは、インターネットからワークロード リソースへの不正なパブリック アクセスを防ぐために、厳密なネットワーク制御が適用されたミッション クリティカルなワークロードを設計するためのガイダンスを提供します。 この目的は、システムの全体的な信頼性が影響を受けないように、ネットワーク層の攻撃ベクトルを停止することです。 たとえば、分散型サービス拒否 (DDoS) 攻撃は、オフのままにすると、不正なトラフィックでリソースを過負荷にしてリソースを利用できなくなる可能性があります。
これは ミッション クリティカルなベースライン アーキテクチャに基づいており、ネットワーク制御なしで信頼性と運用効率を最大化することに重点を置きます。 このアーキテクチャでは、Azure Virtual Network (VNet) とプライベート エンドポイント、Azure Private Link、Azure プライベート DNS ゾーンなどの適切なクラウドネイティブ機能を使用して、イングレスパスとエグレス パスを制限する機能が追加されます。
この記事に進む前に、ベースラインを理解しておくことをお勧めします。
主要な設計戦略
このユース ケースでは、 ミッション クリティカルなベースラインの設計戦略 が引き続き適用されます。 このアーキテクチャの追加のネットワークに関する考慮事項を次に示します。
イングレス トラフィックを制御する
悪意のある攻撃を防ぐために、仮想ネットワークへのイングレス通信または受信通信を制限する必要があります。
グローバル レベルで Web アプリケーション ファイアウォール (WAF) 機能を適用して 、攻撃元に近いネットワーク エッジでの攻撃を停止します。
Azure サービスへのパブリック接続を排除します。 1 つの方法は、プライベート エンドポイントを使用することです。
ネットワークに入る前にトラフィックを検査します。 サブネット上のネットワーク セキュリティ グループ (NSG) は、構成された IP アドレスとポートへのフローを許可または拒否することで、トラフィックをフィルター処理するのに役立ちます。 このレベルの制御は、詳細なログ記録にも役立ちます。
エグレス トラフィックを制御する
仮想ネットワークからそのネットワーク外のエンティティへのエグレス トラフィックを制限する必要があります。 制御が不足すると、悪意のあるサード パーティのサービスによるデータ流出攻撃につながる可能性があります。
Azure Firewall を使用してインターネットへの送信トラフィックを制限します。 ファイアウォールでは、完全修飾ドメイン名 (FQDN) を使用してトラフィックを細かくフィルター処理できます。
セキュリティとのトレードオフのバランスを取る
セキュリティ機能がワークロード アーキテクチャに追加される場合、大きなトレードオフがあります。 パフォーマンス、運用の機敏性、さらには信頼性に影響を及ぼす可能性があります。 ただし、 拒否Of-Service (DDoS)、データ侵入などの攻撃は、システムの全体的な信頼性をターゲットにし、最終的には利用できなくなる可能性があります。
戦略は、 適切に設計されたミッション クリティカルなワークロードにおけるミッション クリティカルなワークロードに対して提供される全体的なガイダンスに基づいています。 独自のミッション クリティカルなアーキテクチャを定義する際の推奨事項とベスト プラクティスについては、 ネットワークと接続の設計領域 を検討することをお勧めします。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャのコンポーネントは、この方法で大まかに分類できます。 Azure サービスに関する製品ドキュメントについては、 関連リソースを参照してください。
グローバル リソース
グローバルリソースは長生きしており、システムの有効期間を共有しています。 複数リージョンデプロイ モデルのコンテキスト内でグローバルに使用できる機能があります。 詳細については、「 グローバル リソース」を参照してください。
Azure Front Door Premium SKU は、プライベート エンドポイントを介して公開されるリージョンデプロイにトラフィックを確実にルーティングするためのグローバル ロード バランサーとして使用されます。
「適切に設計されたミッション クリティカルなワークロード: グローバル トラフィック ルーティング」を参照してください。
Azure Cosmos DB for NoSQL は、コンピューティング クラスターの外部に状態を格納するために引き続き使用され、信頼性のためのベースライン構成設定があります。 アクセスは、承認されたプライベート エンドポイント接続に制限されます。
適切に 設計されたミッション クリティカルなワークロード:グローバル分散マルチ書き込みデータストアを参照してください。
Azure Container Registry は、geo レプリケーション機能を備えたすべてのコンテナー イメージを格納するために使用されます。 アクセスは、承認されたプライベート エンドポイント接続に制限されます。
「適切に設計されたミッション クリティカルなワークロード: コンテナー レジストリ」を参照してください。
地域のリソース
リージョン リソースは、単一の Azure リージョンへの デプロイ スタンプ の一部としてプロビジョニングされます。 ユーザーに対する回復性、スケール、および近接性を高めるために、有効期間が短くなります。 これらのリソースは、別のリージョンのリソースと何も共有しません。 これらは個別に削除することも、他のリージョンにレプリケートすることもできます。 ただし、グローバル リソース は相互に共有されます。 詳細については、「 地域スタンプ リソース」を参照してください。
Azure Storage アカウントの静的 Web サイトは、 バックエンド サービスに要求を送信するシングル ページ アプリケーション (SPA) をホストします。 このコンポーネントの構成は、 ベースライン フロントエンドと同じです。 アクセスは、承認されたプライベート エンドポイント接続に制限されます。
Azure Virtual Networks は、 ワークロードと管理操作を実行するためのセキュリティで保護された環境を提供します。
内部ロード バランサー は、アプリケーションの配信元です。 Front Door では、この配信元を使用して、Private Link を使用してバックエンドへのプライベートおよび直接接続を確立します。
Azure Kubernetes Service (AKS) は、アプリケーションを実行するバックエンド コンピューティングのオーケストレーターであり、ステートレスです。 AKS クラスターはプライベート クラスターとしてデプロイされます。 そのため、Kubernetes API サーバーはパブリック インターネットに公開されません。 API サーバーへのアクセスは、プライベート ネットワークに制限されます。 詳細については、このアーキテクチャの コンピューティング クラスター に関する記事を参照してください。
「適切に設計されたミッション クリティカルなワークロード: コンテナー オーケストレーションと Kubernetes」を参照してください。
Azure Firewall は、Azure Virtual Network リソースからのすべてのエグレス トラフィックを検査して保護します。
Azure Event Hubs は メッセージ ブローカーとして使用されます。 アクセスは、承認されたプライベート エンドポイント接続に制限されます。
適切に 設計されたミッション クリティカルなワークロード(疎結合のイベントドリブン アーキテクチャ)を参照してください。
Azure Key Vault は、 リージョンシークレット ストアとして使用されます。 アクセスは、承認されたプライベート エンドポイント接続に制限されます。
適切に 設計されたミッション クリティカルなワークロード:データ整合性保護を参照してください。
デプロイ パイプライン リソース
検証済みのスタンプをデプロイする一貫した方法を保証するには、ミッション クリティカルなアプリケーションのビルドパイプラインとリリース パイプラインを完全に自動化する必要があります。
GitHub は、高可用性 Git ベースのプラットフォームとしてソース管理に引き続き使用されます。
Azure Pipelines は、 運用前 および 運用環境でのワークロードの構築、テスト、デプロイに必要なパイプラインを自動化するために選択されます。
適切に 設計されたミッション クリティカルなワークロードである DevOps プロセスを参照してください。
セルフホステッド Azure DevOps ビルド エージェント プール は、ビルドとデプロイをより詳細に制御するために使用されます。 コンピューティング クラスターとすべての PaaS リソースがプライベートであるため、このレベルの自律性が必要です。これには、Microsoft がホストするビルド エージェントでは不可能なネットワーク レベルの統合が必要です。
可観測性リソース
グローバル リソースとリージョン リソースの監視データは、個別に格納されます。 単一障害点を回避するために、単一の一元化された監視ストアは推奨されません。 詳細については、「監視リソース」を参照してください。
Azure Log Analytics は、すべてのアプリケーションおよびインフラストラクチャ コンポーネントのログとメトリックを格納するための統合シンクとして使用されます。
Azure Application Insights は、アプリケーションパフォーマンス管理 (APM) ツールとして使用され、すべてのアプリケーション監視データを収集し、Log Analytics 内に直接格納します。
適切に 設計されたミッション クリティカルなワークロード(予測アクションと AI 運用)を参照してください。
管理リソース
ベースライン アーキテクチャからの大幅な設計変更は、コンピューティング クラスターです。 この設計では、AKS クラスターはプライベートです。 この変更では、アクセスを取得するために追加のリソースをプロビジョニングする必要があります。
プライベート ビルド エージェントとジャンプ ボックス インスタンス用の Azure Virtual Machine Scale Sets で、kubectl などのツールをクラスターに対して実行します。
Azure Bastion はジャンプ ボックス VM への安全なアクセスを提供し、VM がパブリック IP を持つ必要がなくなります。
PaaS サービスのプライベート エンドポイント
ビジネス操作またはデプロイ操作を処理するには、アプリケーションとビルド エージェントが、グローバルに、リージョン内、さらにはスタンプ内でプロビジョニングされる複数の Azure PaaS サービスに到達する必要があります。 ベースライン アーキテクチャでは、その通信はサービスのパブリック エンドポイント経由です。
この設計では、これらのサービスは、パブリック インターネット アクセスからそれらを削除するために、プライベート エンドポイントで保護されています。 この方法により、全体的な攻撃対象領域が減少し、予期しないソースからの直接サービスの改ざんが軽減されます。 ただし、別の潜在的な障害点が発生し、複雑さが増します。 このアプローチを採用する前に、セキュリティとのトレードオフを慎重に検討してください。
プライベート エンドポイントは、スタンプの仮想ネットワークの専用サブネットに配置する必要があります。 プライベート エンドポイントへのプライベート IP アドレスは、そのサブネットから割り当てられます。 基本的に、仮想ネットワーク内のすべてのリソースは、プライベート IP アドレスに到達することでサービスと通信できます。 アドレス空間が、そのスタンプに必要なすべてのプライベート エンドポイントに対応できる十分な大きさであることを確認します。
プライベート エンドポイント経由で接続するには、DNS レコードが必要です。 サービスに関連付けられている DNS レコードは、Azure DNS によって処理される Azure プライベート DNS ゾーンに保持することをお勧めします。 完全修飾ドメイン名 (FQDN) がプライベート IP アドレスに解決されていることを確認します。
このアーキテクチャでは、Azure Container Registry、Azure Cosmos DB、Key Vault、Storage リソース、および Event Hubs 用にプライベート エンドポイントが構成されています。 また、AKS クラスターはプライベート クラスターとしてデプロイされ、クラスターのネットワークに Kubernetes API サービスのプライベート エンドポイントが作成されます。
この設計には 2 つの仮想ネットワークがプロビジョニングされており、両方に、すべてのサービスのプライベート エンドポイントを保持するための専用サブネットがあります。 ネットワーク レイアウトについては、「 仮想ネットワーク レイアウト」を参照してください。
アーキテクチャにさらにコンポーネントを追加する場合は、プライベート エンドポイントを追加することを検討してください。 たとえば、 監視リソースに制限を追加できます。 Azure Log Analytics と Azure Application Insights の両方で、プライベート エンドポイントの使用がサポートされています。 詳細については、「 Azure Private Link を使用してネットワークを Azure Monitor に接続する」を参照してください。
同じ仮想ネットワーク内の同じサブネットまたは異なるサブネット上に作成できます。 サブスクリプションに作成できるプライベート エンドポイントの数には制限があります。 詳しくは、Azure での制限に関するページをご覧ください。
サブネット上のネットワーク セキュリティ グループを使用して、サービスへのアクセスをさらに制御します。
プライベート イングレス
Azure Front Door Premium SKU は、すべての着信クライアント トラフィックのグローバル エントリ ポイントとして使用されます。 Web アプリケーション ファイアウォール (WAF) 機能を使用して、ネットワーク エッジでトラフィックを許可または拒否します。 構成された WAF ルールは、スタンプ仮想ネットワークに入る前でも攻撃を防ぎます。
このアーキテクチャでは、バックエンドでパブリック IP/エンドポイントを使用せずに、Azure Private Link を使用してアプリケーションの配信元にアクセスする Front Door の機能も利用します。 これには、スタンプ仮想ネットワーク内の内部ロード バランサーが必要です。 このリソースは、クラスターで実行されている Kubernetes イングレス コントローラーの前にあります。 このプライベート ロード バランサーの上に、Private Link サービスが AKS によって作成されます。これは Front Door からのプライベート接続に使用されます。
接続が確立されると、Front Door ネットワーク上のプライベート エンドポイントは、Private Link 経由でスタンプ ネットワーク内のロード バランサーと静的 Web サイトと直接接続されます。
詳細については、「 Private Link のしくみ」を参照してください。
適切に 設計されたミッション クリティカルなワークロード:アプリケーション配信サービスを参照してください。
制限付きエグレス
アプリケーションでは、いくつかの送信インターネット接続が必要になる場合があります。 そのトラフィックを制御することで、エグレス トラフィックを制限、監視、制限できます。 そうしないと、予期しないインサイド アウト アクセスが侵害され、信頼性の低いシステム状態になる可能性があります。 制限付きエグレスは、データ流出などの他のセキュリティ上の問題にも対処できます。
ファイアウォールとネットワーク セキュリティ グループ (NSG) を使用すると、アプリケーションからの送信トラフィックが検査され、ログに記録されることを確認できます。
このアーキテクチャでは、Azure Firewall は単一のエグレス ポイントであり、仮想ネットワークから送信されるすべての送信トラフィックを検査するために使用されます。 ユーザー定義ルート (UDR) は、アプリケーション サブネットなどのエグレス トラフィックを生成できるサブネットで使用されます。
送信トラフィックの制限については、「 Azure Kubernetes Service (AKS) のクラスター ノードのエグレス トラフィックを制御する」を参照してください。
仮想ネットワークのレイアウト
リージョンリソースと管理リソースを別々の仮想ネットワークに分離します。 これらは、明確な特性、目的、およびセキュリティに関する考慮事項を持っています。
トラフィックの種類: ビジネス運用の処理に参加するリージョン リソースには、より高いセキュリティ制御が必要です。 たとえば、コンピューティング クラスターは、直接インターネット トラフィックから保護する必要があります。 管理リソースは、運用のためにリージョン リソースにアクセスするためにのみプロビジョニングされます。
有効期間: これらのリソースの予想される有効期間も異なります。 地域のリソースは有効期間が短い (エフェメラル) と予想されます。 これらはデプロイ スタンプの一部として作成され、スタンプが破棄されるときに破棄されます。 管理リソースは、リージョンの有効期間を共有し、スタンプ リソースをライブで共有します。
このアーキテクチャには、スタンプ ネットワークと運用ネットワークという 2 つの仮想ネットワークがあります。 サブネットとネットワーク セキュリティ グループ (NSG) を使用して、各仮想ネットワーク内でさらに分離を作成し、サブネット間の通信をセキュリティで保護します。
「適切に設計されたミッション クリティカルなワークロード: 分離された仮想ネットワーク」を参照してください。
リージョン スタンプ仮想ネットワーク
デプロイ スタンプは、各リージョンに仮想ネットワークをプロビジョニングします。
仮想ネットワークは、これらのメイン サブネットに分割されます。 すべてのサブネットには、仮想ネットワークからの承認されていないアクセスをブロックするためにネットワーク セキュリティ グループ (NSG) が割り当てられます。 NSG は、アプリケーション サブネットとネットワーク内の他のコンポーネント間のトラフィックを制限します。
アプリケーション サブネット
AKS クラスター ノード プールは、サブネット内で分離されます。 ワーカー ノード プールからシステム ノード プールをさらに分離する必要がある場合は、それらを別のサブネットに配置できます。
イングレス サブネットにスタンプを付けます
各スタンプへのエントリ ポイントは、専用サブネットに配置された内部 Azure Standard Load Balancer です。 Front Door からのプライベート接続に使用される Private Link サービスもここに配置されます。
両方のリソースは、スタンプのデプロイの一部としてプロビジョニングされます。
エグレス サブネットにスタンプを付けます
Azure Firewall は別のサブネットに配置され、ユーザー定義ルート (UDR) を使用してアプリケーション サブネットからのエグレス トラフィックを検査します。
プライベート エンドポイント サブネット
アプリケーション サブネットは、リージョン スタンプ、Key Vault などの PaaS サービスにアクセスする必要があります。 また、コンテナー レジストリなどのグローバル リソースへのアクセスも必要です。 このアーキテクチャでは、 すべての PaaS サービスはロックダウン され、プライベート エンドポイント経由でのみアクセスできます。 そのため、これらのエンドポイント用に別のサブネットが作成されます。 このサブネットへの受信アクセスは、アプリケーションからのトラフィックのみを許可する NSG によって保護されます。
プライベート エンドポイントの UDR サポートを使用してさらに制限を追加して、このトラフィックがスタンプ エグレス サブネットを通過することもできます。
運用仮想ネットワーク
運用トラフィックは、別の仮想ネットワークで分離されます。 AKS クラスターの API サービスはこのアーキテクチャではプライベートであるため、すべてのデプロイと運用トラフィックも、セルフホステッド ビルド エージェントやジャンプ ボックスなどのプライベート リソースから取得する必要があります。 これらのリソースは、独自のプライベート エンドポイントのセットを介してアプリケーション リソースに直接接続された別の仮想ネットワークにデプロイされます。 ビルド エージェントとジャンプ ボックスは別々のサブネットにあります。
プライベート エンドポイントを使用する代わりに、仮想ネットワーク ピアリングを使用する方法があります。 ただし、ピアリングにより複雑さが増し、特に仮想ネットワークがエフェメラルに設計されている場合は管理が困難になる可能性があります。
ビルド エージェント (および必要に応じてジャンプ ボックス) の両方が、グローバルおよびリージョン スタンプ内にある PaaS サービスにアクセスする必要があります。 リージョン スタンプ仮想ネットワークと同様に、必要な PaaS サービスへのプライベート エンドポイント用に専用サブネットが作成されます。 このサブネット上の NSG により、管理サブネットとデプロイ サブネットからのみイングレス トラフィックが許可されます。
管理操作
一般的なユース ケースは、オペレーターが管理ツールとコマンドを実行するためにコンピューティング クラスターにアクセスする必要がある場合です。 プライベート クラスター内の API サービスに直接アクセスすることはできません。 そのため、オペレーターがツールを実行できるジャンプ ボックスがプロビジョニングされます。 ジャンプ ボックスには別のサブネットがあります。
ただし、これらのジャンプ ボックスは、未承認のアクセスからも保護する必要があります。 RDP/SSH ポートを開くことでジャンプ ボックスに直接アクセスすることは避ける必要があります。 この目的には Azure Bastion をお勧めします。この仮想ネットワークには専用のサブネットが必要です。
注意事項
Azure Bastion とジャンプ ボックスを介した接続は、デバッグ ツールの実行に追加のプロセスが必要になるなど、開発者の生産性に影響を与える可能性があります。 ミッション クリティカルなワークロードのセキュリティ強化を決定する前に、これらの影響に注意してください。
SSH 経由で Bastion サブネットからの受信トラフィックのみを許可する NSG を使用して、ジャンプ ボックス サブネットへのアクセスをさらに制限できます。
デプロイ操作
デプロイ パイプラインを構築するには、ビルド エージェントを実行するために追加のコンピューティングをプロビジョニングする必要があります。 これらのリソースはワークロードのランタイムの可用性に直接影響を与えませんが、信頼性の障害により、ミッション クリティカルな環境をデプロイまたはサービスする機能が危険にさらされる可能性があります。 そのため、信頼性機能をこれらのリソースに拡張する必要があります。
このアーキテクチャでは、(1 つの VM ではなく) ビルド エージェントとジャンプ ボックスの両方に仮想マシン スケール セットが使用されます。 また、ネットワークのセグメント化は、サブネットを使用して提供されます。 イングレスは Azure DevOps に制限されます。
コストに関する考慮事項
ミッション クリティカルなワークロードのコストには大きな影響があります。 このアーキテクチャでは、Azure Front Door Premium SKU の使用や各スタンプでの Azure Firewall のプロビジョニングなどのテクノロジの選択により、コストが増加します。 また、メンテナンスと運用リソースに関連する追加コストもあります。 このようなトレードオフは、ベースライン アーキテクチャのネットワーク制御バージョンを採用する前に慎重に検討する必要があります。
このアーキテクチャをデプロイする
このアーキテクチャのネットワークの側面は、ミッション クリティカルな Connected 実装で実装されます。
注
Connected 実装は、組織のリソースに依存し、他のワークロードと統合し、共有サービスを使用するミッション クリティカルなワークロードを示すことを目的としています。 このアーキテクチャに基づいており、この記事で説明されているネットワーク コントロールを使用します。 ただし、接続済みシナリオでは、仮想プライベート ネットワークまたは Azure プライベート DNS ゾーンが Azure ランディング ゾーン接続サブスクリプション内に既に存在することを前提としています。
次のステップ
このアーキテクチャで行われた設計上の決定の詳細については、Azure Well-architected Framework のミッション クリティカルなワークロードのネットワークと接続の設計領域を確認してください。
関連リソース
このアーキテクチャで使用される Azure サービスに関する製品ドキュメントについては、次の記事を参照してください。