Cisco Cloud Application Centric Infrastructure（Cloud ACI）によるアプリケーション サービス チェーンの強化
この記事は、Geetha Anandakrishnan によるブログ「How Cisco Cloud Application Centric Infrastructure (Cloud ACI) powers Application Service Chaining
」（2021/7/13）の抄訳です。
以前、「Power Chain of Cloud Application Centric Infrastructure（Cloud ACI）in Service Chaining [英語]」というブログ記事を投稿しました。そこでは、パブリッククラウドのネイティブロードバランサのライフサイクル管理に Cloud ACI が優れたソリューションを提供する仕組みについて説明しました。また、トラフィックがアプリケーション ロードバランサに到達する前にファイアウォールを挿入する簡単なユースケースも紹介しました。今回の記事では、Cisco ACI の包括的なサービス チェーン フレームワークを使用して解決できる、より複雑なユースケースについて説明します。
シームレスなファイアウォール挿入によりワークロードを保護
パブリッククラウドではセキュリティが最重要課題となります。お客様がトラフィック検査の対象としたいのは、インターネットからパブリッククラウド内のお客様のアプリケーションに着信するトラフィックだけではありません。パブリッククラウド内のトラフィック、つまり VPC（AWS）内 /VNET（Microsoft Azure）内のトラフィックも対象にしたいと考えています。Azure 内の別々の仮想ネットワークで各アプリケーションを実行しているお客様の例を見てみましょう。Web VNET 内の Web アプリケーションのトラフィックは、アプリケーション層の VNET で実行されているバックエンド アプリケーションに送信される前に検査する必要があります。そこで、ファイアウォールや侵入検知システム（IDS）、侵入防御システム（IPS）のデバイスを 2 つのアプリケーション間のパスに挿入するのが一般的です。Web アプリケーションによって送信されたトラフィックは、IDS や IPS にリダイレクトされます。バックエンド アプリケーションに送信されるのは、検査デバイスで問題がないと判断された場合のみとする必要があります。
Cloud ACI は、ネットワーキングだけでなく、Web 層サーバからアプリケーション層サーバまで、またその間に存在するあらゆるセキュリティグループの設定をシームレスに自動化します。この自動化は、サービスチェーンと 2 つのアプリケーション間の取り決めに基づいて実施されます。検査デバイス（IPS/IDS）は通常、高可用性のニーズに対応するため、ネットワークロードバランサの背後に配置されます。トポロジは次のようになります。
上の図では、バックエンド アプリケーションの前面に、Azure ではアプリケーション ゲートウェイ（AGW）と呼んでいるアプリケーション ロードバランサが配置されています。ここで注意していただきたいのは、Web サーバは、AGW によってホストされているバックエンド アプリケーションの仮想 IP（VIP）と通信しており、ファイアウォールについては認識していないということです。では、2 つのアプリケーション間のパスにファイアウォールを挿入するにはどうすればよいのでしょうか？
Cloud ACI の可能性をあますところなく実感
Cloud ACI は、サービスグラフの設定という非常に柔軟なモデルを提供します。お客様は、真に革新的な方法でファイアウォールを挿入できます。サービスチェーンを指定するネットワークロードバランサ（NLB）、ファイアウォール、アプリケーション ロードバランサを追加して、サービスグラフを作成します。NLB を追加する際、サービスグラフで、コンシューマコネクタとプロバイダーコネクタの「リダイレクト」オプションを指定できます。
このオプションを選択すると、アプリケーション層を宛先とする Web VNET のトラフィックが NLB にリダイレクトされます。同様に、アプリケーション層から Web へのリターンフローも NLB を経由します。
Cloud ACI は、Web VNET ルートテーブルでユーザ定義ルート（UDR）を自動的にプログラミングすることでこれを実現します。次の図に示すように、ルートは AGW VIP を宛先とするトラフィックのネクストホップとして NLB VIP を参照します。
このユースケースでは、ファイアウォールは通常ワンアームモードで導入されます。Web VNET にインストールされた UDR は、NLB 経由でアプリケーション VIP 12.1.0.10 宛てのトラフィックをリダイレクトします。このソリューションでは、Azure NLB が提供する高可用性ポート構成を使用しています。
NLB は、トラフィックのポート/プロトコルに関係なく、受信したすべてのトラフィックをバックエンドに渡すことができます。こうして、NLB は Web サーバから受信したすべてのトラフィックをファイアウォールに送信します。ファイアウォールは検査後、トラフィックを実際の宛先である 12.1.0.10 に送信します。なお、このフローでは、パケットの送信元と宛先の IP は変更されません。送信元は Web サーバの IP のまま、宛先は AGW IP のままです。ネットワークアドレスの変換が発生しないため、デバッグフローが非常に簡単になります。Cloud ACI は、このフローのすべてのホップでネットワーク セキュリティグループを作成、プログラムします。
これにより、クラウドネットワークとセキュリティポリシーを完全に自動化できます。なお、Web VNET と App VNET が異なる地域にある場合でも機能します。ネットワーク内の複雑なサービスチェーンを手動で設定する必要はありません。
この機能の利点を最大限引き出せるのは、Azure 向け Cloud ACI のリリース 5.0(2) 以降です。ぜひお試しください。クラウドで L4 ～ L7 サービスの自動化を開始するには、こちらの詳細手順[英語]を参照してください。
Tags:
