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