CN-Series ファイアウォール: Kubernetesのための包括的ネットワークセキュリティ

This post is also available in: English (英語)

はじめに

「どうすれば企業で利用するコンテナに効果的なネットワークセキュリティを展開できるのか。」この課題は、複雑な従来型アプリケーションの仕分けとコンテナ化が進むなかで、ネットワーク セキュリティ担当部門にとってのもっとも重要な課題の1つとなりました。クラウド ネイティブ アプリケーションがコンテナやサーバーレス、PaaSなどのテクノロジにいかに依存しているかを考えれば、なおさらこの課題の重要性がわかるでしょう。先日公開となったパロアルトネットワークスのCN-Seriesコンテナ ファイアウォールは、Kubernetesを利用するお客様の抱えるそうした懸念を深く理解したうえで、コンテナのためのネットワークセキュリティの課題に応える製品にしあがっています。

一貫したセキュリティは依然Kubernetesにおけるセキュリティの重要課題

コンテナを利用することでDevOps部門の進捗が早まり、ソフトウェアのデプロイを効率化でき、コンピューティング リソースを節約でき、開発もシンプルになることから、昨今ますます多くの企業がアプリケーション開発にKubernetesやコンテナを利用したいと考えるようになってきています。

Kubernetesは、コンテナを使ってアプリケーション開発を自動オーケストレーションすることにより、こうした開発環境には欠かせない重要な役割を果たしています。ところが、ホスト間・コンテナポッド間のネットワークトラフィックは、攻撃者にとってもチャンスを生みだしています。しかもコンテナはミッション クリティカルなアプリケーションに接続する頻度が高いことから、常に包括的なネットワークセキュリティを必要としています。

2019 Cloud Native Computing Foundation(CNCF)の調査によれば、回答者の78%が「本番環境でKubernetesを使用している」ことが示されています。つまり、セキュリティは依然として大きな懸念の1つなのです。そうした懸念については、昨年一年間で筆者がお話した50社以上のお客様からも繰り返し聞かされてきましたが、そのさい話題にのぼるのが「パブリック・プライベートの両クラウドのコンテナを保護する一貫した戦略を編みだすことの難しさ」でした。

とくに彼らがはっきりとその重要性を強調していたのが、次の3つの大きなコンテナ セキュリティに関する課題です。 

  1. DevOps部門がインフラに展開したコンテナをネットワークセキュリティ担当部門が保護するのだが、そのさいネットワークセキュリティ担当部門がコンテナを可視化できていない。この懸念を口にされるお客様は一番多かったです。 
  2. コンテナが仮想マシンなど他の種類のワークロードで使用される機会が増えた。このためこうしたワークロードの保護に一貫したネットワーク セキュリティが求められている。 
  3. セキュリティやファイアウォールとそれ以外のコンテナ化されたアプリケーションスタックとのオーケストレーションをどうやっていけばよいか。

Kubernetesには独自のネットワーク セキュリティ要件がある

Kubernetesで包括的セキュリティを確保するには、その前にKubernetesにおけるネットワークのしくみを理解しておかなければなりません。Container Network Interface (コンテナ ネットワーク インターフェイス、CNI) は、コンテナ間通信を可能にする仕様を定義したCloud Native Computing Foundation (CNCF) のプロジェクトで、Kubernetesはポッド間通信用のCNIプラグインをサポートしています。次の図で示したように、アプリケーション ポッドとのインバウンド、アウトバウンド 、東西の各フローに関連するトラフィックを確認するには、ネットワークパス上の最適な場所にファイアウォールを配置してやる必要があります。

この図は、CN-Series ファイアウォールをネットワークパス上の最適な場所に配置し、アプリケーションポッドとの間のインバウンド、アウトバウンド、東西の各フローに関連するトラフィックを確認できるようにする方法を示している
コンテナ ネットワーク インターフェイス (CNI) とコンテナ ファイアウォールの配置。CNCF の CNI 文書を参考に作成。

ここでパロアルトネットワークス CN-Series ファイアウォールのCNIチェーンの機能が活きてきます。CN-Series は業界初のコンテナ化された次世代ファイアウォール製品で、AWS EKS、Azure AKS、Google GKE、OpenshiftなどほとんどのKubernetesベース環境でコンテナ化されたアプリケーションを保護できるように設計されてれています。 

CN-Series ファイアウォールは詳細なコンテナ コンテキストを使い、エンタープライズIT環境のさまざまなコンポーネントにくわえ、コンテナ トラスト ゾーン間のインバウンド、アウトバウンド、東西の各トラフィックをも保護します。DevOpsのスピードやアジリティに対応するため、CN-SeriesはネイティブのKubernetesオーケストレーションを最大限に活用し、継続的インテグレーション/継続的開発(CI / CD)のプロセスに直接組み込まれています。

そのためのしくみを説明しましょう。CN-SeriesファイアウォールのPAN-OSは、2つのコンテナに分かれています。1つは管理プレーンとして動作し、もう1つはデータプレーンとして動作します。先に説明したCNIチェーンによって、包括的セキュリティが必要とされるアプリケーション ポッドのトラフィックは、確実にデータプレーンを流れるようになります。Kubernetes上でコマンドを1つ実行するだけでKubernetesクラスタ内のすべてのノードにCN-Seriesを同時にデプロイできることから、結果的に開発環境に不可欠なスピードやシンプルさを保つことができるのです。

これには各アプリケーションの正体を見極めることが重要となります。そこで私たちはCN-SeriesをKubernetesネットワークアーキテクチャに特化して設計し、App-IDや脅威検査、DNSセキュリティ、WildFire、URLフィルタリングなど、重要なセキュリティサービスを利用できるようにしています。サポート対象環境の全リストについてはCN-Seriesのデータシート参照してください。

セキュリティはKubernetesネイティブのセキュリティ オートメーションに従って行われるべきである

コンテナの主な利点の1つは自動化です。CN-Series ファイアウォールはそれ自体がコンテナ化されているので、コンテナにもしっかりセキュリティ対策が行われていることが容易に確認できるようになります。くわえて、ネットワーク セキュリティ担当部門とDevOps担当部門とが協力し、Kubernetes環境でのファイアウォールのプロビジョニング計画を立てやすくなります。

たとえばKubernetesの専門家の多くは、コマンドラインツールKubectlを直接利用していますし、DevOps部門も複雑なKubernetesアプリケーションの定義・インストール・アップグレードを支援してくれるHelmパッケージマネージャーを重用することが多くなっています。

この図は、Helm、Terraform、GKE/AKS/EKS、OpenShiftなどKubernetesツール群を俯瞰したさいのCN-Series ファイアウォールの位置づけを示したものです。
CN-Series と Kubernetes ツール

ほかの部分でIaC(IaCテンプレート)にTerraformを使用していてTerraformソフトウェアにすでに慣れているお客様であれば、TerraformとHelmとを組み合わせて使用することもできます。お使いのファイアウォールのライフサイクルを簡単に管理できるよう、パロアルトネットワークスではコミュニティがサポートしているHelm チャートTerraformテンプレートを公開しています。

クラウド空間、コンテナ化されたアプリケーション空間でオペレーションやセキュリティを継続的に行うには、選択的にトラフィックの振り分けができること、しかもそれが容易に自動化できることが重要です。CN-Seriesであれば、アプリケーション管理部門がYAMLファイル内に1つアノテーション(注釈)を追加するだけで、セキュリティを必要とするアプリケーションを示すことができます。CI/CDパイプラインにチェックを追加することで、PCIデータを処理するアプリケーションなど、厳しいネットワーク セキュリティ要件を伴うアプリケーションに対し、次世代ファイアウォールのセキュリティ対策が有効になっていることを確認することができます。これにより、DevOps部門とネットワーク セキュリティ担当部門とが容易に協力しあえるようになります。

一貫したセキュリティポリシーと脅威防御がすべて

多くの企業はネットワーク上でVMやベアメタル、コンテナなどさまざまな形態でアプリケーションを実行していますが、そうした形態のちがいに関係なく、アプリケーションに一貫したポリシーを適用する機能を求めています。 

弊社製品をご利用中のお客様は、既存のファイアウォールにセキュリティポリシーを設定済みですので、Kubernetesのラベルを活用し、既存ポリシーをコンテナ化されたワークロードにも拡張できるCN-Seriesの登場には、高い期待をお寄せいただいております。名前空間、サービス、レプリカセット、ポッドに添付されたラベルを使ってポリシーを構築できるということは、アプリケーションをスケールしてもポリシーを更新する必要がないことを意味しています。 

コンテナ化されたアプリケーションの大多数には既知・未知の脆弱性があります。いずれであれネットワーク上で悪用される可能性があることは意識しておかねばなりません。CN-Seriesには豊富な脅威防御機能が揃っており、こうした機能で既知のマルウェア、脆弱性の悪用、C2トラフィックを自動的にブロックします。この結果、対応に要するリソースや煩わしさ、遅れなどを削減することができます。弊社は、Kubernetes、Docker、Openshiftなどのコンテナ化されたインフラ コンポーネントにくわえ、Redis、MongoDB、WordPress、Nginxなどコンテナ化されることの多いアプリケーションにも脅威対応の幅を広げています。以下に示すように、ポリシーの自動化はパロアルトネットワークスの Cortex XSOARとPAN-OSとの統合によって実現することができます。 

この図ではポリシーを自動化し、Cortex XSOARと統合する方法について説明したものです。ここではデータが検出ソースから取り込まれ、インシデント レスポンス ツールへと流れていく様子が描かれています。
CN-Seriesのポリシー自動化とCortex XSOARとの統合

弊社は、コンテナを採用するのであれば、CI/CDパイプラインのコンテナ レジストリのスキャンから運用環境でのネットワークセキュリティにいたるまでの包括的な保護が必要である、と確信しています。そのために私たちはもっとも包括的な製品スイート、Prisma CloudCN-Series ファイアウォールをつくりだし、お客様がコンテナ採用の旅へと踏み出すにあたってセキュリティの懸念に邪魔されないようにしました。

「どうすれば企業で利用するコンテナに効果的なネットワークセキュリティを展開できるのか。」CN-Seriesがどのようにしてこのホットなコンテナ セキュリティの課題を解決してくれるのか、その技術的詳細を確認するには、CN-Series TechDocsにアクセスしてください。