サービスメッシュプラットフォームによるコンテナクラスタの可視化

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

概要

サービスメッシュプラットフォームは、アプリケーションがデータを共有する方法のきめ細かな制御に特化したインフラレイヤです。標準的な使用例としては、本番用Webベースアプリケーションが新バージョンにあがったとき、それに対するネットワークトラフィックのフローやレートを制御することがあげられます。新しいWebアプリケーションをオンラインにするときは、そのアプリケーションをテストして、ある一定レベルのパフォーマンスを問題なく処理できることを確認しなくてはいけません。サービスメッシュプラットフォームを使えば、ネットワーク内のネットワークトラフィックのフロー制御や、Webベースアプリケーション群のネットワークトラフィックの負荷分散が容易になります。

それだけでなく、サービスメッシュプラットフォームは、ともすればマイクロサービス環境でセキュリティ実務家にとってはブラックボックスになりがちな、Kubernetes(K8s)クラスタ内のコンテナプロセスとそのネットワーク運用の動的監視についての深い洞察を提供してくれます。本稿は、クラウドマイクロサービスアーキテクチャの直面する脅威と、Istio、Linkerd、ConsulなどのサービスメッシュプラットフォームがK8sクラスタ内で発生するセキュリティインシデントの可視性をいかに高めてくれるかに光を当てます。

開発運用(DevOps)チームは、今日の進化するクラウドコンピューティング環境での運用や収益維持にたえられるよう、動的にスケールでき、ステートレスで、イミュータブルで、かつエフェメラルなコンテナ化アプリケーションを設計しています。

ところが、TeamTNT、WatchDog、Nobelium(SolarWinds Orionサプライチェーン攻撃の黒幕とされるグループ)などの悪意のある攻撃者グループが、コンテナアプリケーションを直接標的にしている様子が観測されています。これらの攻撃ではエフェメラルかつイミュータブルなインスタンスの侵害が成功してしまい、侵害されたコンテナのエスケープと、さらなる不正行為のために設計された追加コンテナの起動を許してしまうことになりました。

残念ながら、K8sクラスタ内の可視性欠如により、セキュリティ運用チームにはこうしたアクティビティを知るすべがありません。

TeamTNTは、K8sアプリケーションを標的とする脅威アクターの代表例です。とくにAtlassian Confluenceアプリケーションに対するアプローチという点では、その手の脅威アクターの代表例と言えるでしょう。TeamTNTのアクターは、 CVE-2021-26084のエクスプロイトを積極的に使用していますが、このアプリケーションを狙う脅威アクターのグループは彼らだけではありません。本稿執筆時点でShodanのリストには全世界のインターネットに面した976台のAtlassian Confluenceサーバー(重複なし)が掲載されています(図1参照)。つまりそれだけTeamTNTその他のアクターグループにクラウドシステム侵害の機会を与えていることになります。なお、公開されているこれらのサーバーに、既知のエクスプロイトに対する脆弱性がない可能性はあります。

Atlassian Confluenceの例では、少なくともTeamTNTの観点から見たクラウドKubernetesコンテナに対する活発なクリプトジャック攻撃の様子が浮かび上がります。とはいえクラウドコンテナ内で動作する公開Atlassian Confluenceはそうしたアプリケーションのほんの一例に過ぎません。

もっと一般的なコンテナ型アプリケーションにも同様のリスクがあるのでしょうか。そこで私たちリサーチャーはDocker Hubに掲載されているコンテナイメージのダウンロード数上位20件を分析してみました。この分析で注目すべきは、Atlassian Confluenceがこの上位20件には含まれていないことでしょう。ただ、Webサービスアプリケーションやデータベースアプリケーションなどの、より一般的で潜在的に公開されている可能性の高いクラウドベースアプリケーションに対する攻撃が行われているのかどうかについては、情報がほとんどありません。この点は「マイクロサービスインフラの直面する脅威をセキュリティ対策ツールで検知するにはもっと可視性をあげなければならない」とする根拠となるでしょう。

Prisma Cloud Defenderエージェントは本稿で述べた可視化の一助となります。

目次

サービスメッシュアーキテクチャ
より広いエコシステム
セキュリティに特化したサービスメッシュアーキテクチャの例
セキュリティに特化したサービスメッシュの実現
ランタイムモニタリング
ネットワークトラフィック監視
結論

サービスメッシュアーキテクチャ

Istio、Linkerd、Consulが提供するようなサービスメッシュプラットフォームは、主にDevOpsによって、K8sクラスタ内でホストされている相互接続型マイクロサービス間のネットワーク通信経路の安全確保手段として利用されてきました。サービスメッシュプラットフォームは、信頼性・安全性・可観測性(オブザーバビリティ)などの機能を提供し、個々のマイクロサービスの編成・監視・セキュリティ確保プロセスをより保守管理しやすくすることで安全性を高めています。

大手企業ではすでに自社K8s(Kubernentes)環境にサービスメッシュアーキテクチャを採用していて、このことは組織の採用しているさまざまなテクノロジをなかば匿名で記録・表示している「HGインサイト」からもわかります。 本稿執筆時点で、こうしたプラットフォームを利用している組織の数は以下のようになっていました。

• Consul: 5,588社
• Istio: 3,473社
• Linkerd: 643社

たしかにこれだけの企業がサービスメッシュアーキテクチャを使用してはいますが、同アーキテクチャの提供するテレメトリ情報が既存セキュリティオペレーションセンター(SOC)のツールセットと統合されているのかどうかや、統合している場合はそれをどのように行っているのかについてはわかっていません。

わかっているのは、「サービスメッシュプラットフォームをうまくつかえば、負荷分散処理をやりつつ、トラフィックのミラーリングで既に使っているのと同じ機能を活かして、セキュリティチームがK8sクラスタ内の可視化への道を開ける」ということです。

サービスメッシュ活用で知見を増やす方法を解説する前に、そもそもなぜ業界としてより多くの知見を得る必要があるのかについてお話したいと思います。

より広いエコシステム

サービスメッシュプラットフォームは、侵害後のコンテナがとったアクションをセキュリティチームが監視するのに役立ちます。では、エフェメラルでイミュータブルなステートレスコンテナは、どんな方法で侵害されているのでしょうか。

たとえばK8sクラスタでホストされているAtlassian Confluenceアプリケーションを狙い、同アプリケーションの既知のエクスプロイトを使っているTeamTNTは、その格好の例といえるでしょう。ただ、もっと一般的なコンテナアプリケーションをターゲットにするのに使えそうな既知のエクスプロイトは他にもあるのでしょうか。

以下は、上位20種類のコンテナアプリケーションそれぞれに関連する既知のエクスプロイトの数(図2)と、そのアプリケーションに関連する既知の公開インスタンス数(図3)を示したものです。ExploitDBからエクスプロイト統計情報を取得しShodanから公開インスタンス数を割り出しました。各知見に記載の値は本書執筆時点のものです。

コンテナアプリケーションの上位20位内だけでも合計で1,989種類のエクスプロイトがリストアップされています。なおこの後インフラストラクチャ・アズ・コード(IaC)テンプレート内の脆弱性数について追加で調査した結果は2021年下半期のUnit 42クラウド脅威レポートにまとめて公開しています。

これら上位20個のアプリケーションのうち、13個のアプリケーションには少なくとも1つの既知のエクスプロイトが存在し、4つのアプリケーションについては少なくとも90個のエクスプロイトが存在します(表1参照)。K8sクラスタ内に最新のアプリケーションをデプロイし、既知のエクスプロイトに対して脆弱性でないことを確認することは、きわめて重要です。

^{表1 ダウンロード数の多いコンテナイメージのうち既知のエクスプロイト数が多いもの上位5つ}

図3は上位20個のイメージそれぞれについて、既知の公開インスタンスの状況を別の視点から示したグラフです。このグラフはホストされているクラウドサービスプロバイダ別でみた各アプリケーションの公開インスタンス数を示したものです。興味深い点をいくつか取り上げてみましょう。公開された Python、httpd、nodeインスタンスはその大半がAmazon Web Servicesでホストされています。また、公開されたPostgreSQLとMySQLのインスタンスの大半をホストしているのはGoogle Cloudです。おそらく最も興味深い発見は、2022年4月4日時点で分析した上位20個のコンテナイメージのほぼすべてで、一般公開されたインスタンスの大部分をホストしているのはDigitalOceanという点でしょう。DigitalOceanのユーザーがほかのCSPユーザーと比べてアプリケーションを公開してしまいがちな理由はよくわかりませんが、これは複合的要因によるものかもしれません。たとえば価格が安ければユーザーはクラウドインスタンスの立ち上げを拙速に行う傾向があり、これがセキュリティベストプラクティスを軽視するユーザー層を引きつけてしまっている可能性があります。

これらのアプリケーションには、nginxやhttpdなどのWebサービスのように一般公開が前提で設計されているものもあります。ただしpostgres、mongo、mysql、mariadbなどのデータベースアプリケーションは、セキュリティベストプラクティスとして、決して直接公開されるべきではありません。ユーザーやクラウドアーキテクトは、公開を必要とするアプリケーションにのみ公開を許可し、その他のアプリケーションは公開されないようにするだけで、クラウドセキュリティを劇的に向上させられます。

自社がクラウドプラットフォームでクラウドインスタンスをホストしている場合、「組織のクラウドリソースの監査を行い、プラットフォームユーザーが当該クラウドインフラを適切に保護しているか確認すること」をUnit 42のリサーチャーは推奨しています。またリサーチャーは、ユーザーに「不要なクラウドベースアプリケーションが一般公開されないよう、これらの検出・緩和用に設計されたCloud Native Application Protection Platform(CNAPP)を導入すること」を推奨しています。

読者の皆さんにここで仮定の質問をしてみます。「Atlassian Confluenceが脅威アクターに広く狙われていることがわかっており、しかもこのイメージがもっとも人気のあるコンテナイメージのトップ50にすら入っていないとしたら、数百個の既知の脆弱性をもつほかのコンテナアプリケーションはどのぐらい脅威アクターに狙われているのでしょうか?」「これらのコンテナが侵害された場合、セキュリティチームやツールはそのコンテナで悪質なオペレーションが行われていないことを監視できているのでしょうか?」

セキュリティに特化したサービスメッシュアーキテクチャの例

では「セキュリティに特化したサービスメッシュアーキテクチャ」とはどのようなものでしょうか。図4を参照してください。このアーキテクチャでは、サービスメッシュアーキテクチャにもとからあるネットワークトラフィックの監視機能とミラーリング機能を活かし、SOCでよく使われているセキュリティツールにトラフィックをミラーリングできるようにしています。これでK8sクラスタ内のネットワークトラフィックが分析できるようになります。

さらにCloud Workload Protection Platform(CWPP)のようなクラウドネイティブテクノロジ(Prisma Cloud Computeもその1つ)を使えば、ユーザーはK8sクラスタ内のランタイムコンテナオペレーションを監視し、悪意のあるプロセスやネットワークトラフィック、API接続を検出・緩和できるようになります。CWPPのようなクラウドネイティブテクノロジは、サービスメッシュプラットフォームと連携して同プラットフォームの機能を拡張し、処理リソースのオーバーヘッドをさほど増やさずに、コンテナのホストシステムから直接コンテナの監査可能イベントを収集できるようにしてくれます。

セキュリティに特化したサービスメッシュの実現

Prisma Cloud ComputeのようなCWPPは、K8sクラスタ内のプロセス監視機能を提供し、DevOpsの継続的インテグレーション・継続的開発(CI/CD)パイプラインのための強固なシフトレフトなスキャン機能も組み込みます。シフトレフトスキャンを実装することで、組織のクラウドインフラ侵害プロセスはいっそう困難になります。これにより、組織のセキュリティリスク露出が劇的に改善されます。

ただし、スキャンをしただけでデプロイ後の漏えいを防げると考えたり、誤った安心感をもってはいけません。スキャンはクラウドインフラの最初の侵害が起こりにくいようにしてくれるというだけで、すでに侵害されてしまった後や、いままさにセキュリティインシデントが発生しているというときに、可視化や監視機能や警告を提供してくれるわけではありません。

そこで登場するのがサービスメッシュのセキュリティソリューションです。サービスメッシュはマイクロサービスインフラの可視性を高めてセキュリティを強化してくれ、CWPPやCSPM(クラウドセキュリティ態勢管理)ソリューションから収集したインテリジェンスとも連動させられます。

そこではPrisma Cloud ComputeのようなCWPP製品がコンテナ内でのランタイムモニタリングを提供し、弊社のCN-Seriesのようなファイアウォール・アズ・ア・プラットフォーム(FWaaP)ソリューションが、URLフィルタリングとレイヤ7検出メカニズムを提供します。サービスメッシュソリューションはこれら両方のソリューションと統合でき、マイクロサービス間のTLS相互認証(mTLS)の暗号化機能や、ネットワークトラフィック分析専用アプリケーションへのネットワークトラフィックミラーリング機能により、マイクロサービスを標的とするネットワークベース攻撃への洞察を深め、セキュリティ保護を強化します。

ランタイムモニタリング

CWPPのランタイムモニタリングアプリケーションまたはエージェント(Prisma CloudのDefenderエージェントなど)は、各K8sクラスタ内にインストールされると、コンテナが処理した監査可能データを送信し、そのデータは集中管理用を行うセキュリティアプリケーションに送り返されます。

なお、SIEM(セキュリティ情報イベント管理)やエンドポイント検出・対応(EDR)エージェント、あるいは各種オープンソースログ収集ツールなどのセキュリティツールのなかには、クラウドネイティブではなく、K8sクラスタ自体にインストールできないものもたくさん存在します。こうしたクラウドネイティブではないツールが利用されていても、クラウドベースの仮想マシンにこれらのツールをインストールできる可能性は十分にありますし、ほとんどのサービスメッシュプラットフォームはサイドカーアプリケーションのインストールが許可されています。サイドカーは、サービスメッシュプラットフォームでよく使われるアーキテクチャコンポーネントで、1つのコンテナでK8sクラスタ内のコンテナからテレメトリを収集できるようにするものです。サイドカーは伝統的にリソース要件が小さく、平均でvCPUが1つ未満、RAMが40MB未満ほどです。サイドカーはコンテナデータを集中管理用のセキュリティアプリケーションに中継するだけなので、さほどリソースを必要としません。サイドカーのパフォーマンスについては、IstioのサイドカーとConsulサーバーのパフォーマンスメトリクスを参照してください。

誤解のないようにいっておくと、どんなランタイムモニタリングツールにもなんらかのリソース要件は発生します。ただ、とくにセキュリティ侵害発生時にはセキュリティインシデントデータの収集が必要となることを考えれば、コンテナの運用で収集されるセキュリティの可視性の高さは重要なインセンティブといえます。

またこのレベルの可視性があれば、社内の脅威ハンターが組織のクラウドインフラを標的とする最先端クラウドマルウェアの来たる攻撃波を検出できるようになるかもしれません。詳細なランタイムモニタリング機能を持っていれば、クラウドインフラをいつでも安全で動的でスケーラブルなものにしてくれる防御策が手に入ります。

ネットワークトラフィックの監視

ネットワークトラフィックの監視でサービスメッシュプラットフォームの真価が問われます。サービスメッシュプラットフォームは、クラスタ内で実行されているすべてのマイクロサービスにmTLSを提供することで、K8sクラスタのセキュリティ衛生を劇的に向上させます。これは、クラスタ内のサービス間ネットワーク通信がすべて暗号化されることを意味します。

さらに、サービスメッシュプラットフォームでは、統合されたサイドカーのプロキシにより、K8sクラスタ自体のトラフィック負荷分散処理をカスタマイズできます。サービスメッシュプラットフォームではCSPレベルでネットワークトラフィックを負荷分散する代わりにクラスタ内でネットワークトラフィックを負荷分散できるので、DevOpsチームがアプリケーションの新バージョンを段階的にロールアウトできるようになります。このほか、余計なK8sクラスタの作成や複雑なクラウドプラットフォームの負荷分散処理を行うことなく、A/Bテストを実施することもできます。

サービスメッシュプラットフォームを介したK8sクラスタのネットワーク監視は、必要とされているセキュリティ運用も提供できます。サービスメッシュのネイティブなレイヤ7の可視性を使えば、メッシュは1つまたは複数のシステム、ネームスペース、またはK8sクラスタ全体に対し、任意またはすべてのトラフィックをミラーリングできます。

また、OSI(Open Systems Interconnection)モデルの任意のレイヤでのネットワークトラフィックミラーリングが可能なので、セキュリティ監視ツールの統合も可能です。URLフィルタリングとDNS監視サービスを統合することで、ネットワークトラフィックインジェクション攻撃や中間者攻撃(MITM)、分散型サービス拒否攻撃(DDoS)などのネットワークベースの攻撃を検知・防止できます。さらに、サービスメッシュプラットフォームは、CSPのアイデンティティおよびアクセス管理(IAM)ツールの統合にも道筋をつけてくれ、セキュリティチームがK8sクラスタ内の特定のマイクロサービスにアクセス制御を統合できるようにします。ホスティングされたクラウドプラットフォーム内で、ユーザーとサービスアカウントに指定された同一のIAMポリシーを使うことで、セキュリティチームがK8sクラスタ内のユーザーアクセスをより詳細なレベルで管理することもできます。

結論

Consul、Istio、Linkerdなどのサービスメッシュプラットフォームは、コンテナ環境内でセキュリティのベストプラクティスを維持するために最も重要なものです。ところがクラウド環境のセキュリティに特化した運用において、その役割はまだ十分に開花しているとは言えません。具体的にいえば、サービスメッシュプラットフォームはすべてのK8sポッド・ネームスペースにわたるネットワーク監視ツールをセキュリティに特化した単一のサードパーティ製アプリケーションに統合できることから、セキュリティチームによるセキュリティ監視タスクを劇的に容易にしてくれるのです。

Prisma Cloud DefenderエージェントはK8sクラスタにインストールすることができるので、これによりセキュリティチームはK8sクラスタでホストされているコンテナのランタイムオペレーションを監視できるようになります。サービスメッシュプラットフォームは、K8sクラスタ内のデータのネットワークミラーリングとモニタリングコンポーネントにフォーカスしています。K8sクラスタ内のネットワークトラフィックを中心としたアラートの監視・調査・対応機能を持つサービスメッシュプラットフォームは、K8sクラスタでぜひとも必要とされている可視性を提供してくれます。この可視化により今日のクラウドマイクロサービスが直面している脅威に光を当てることができ、これによりセキュリティ運用チームはクラウドインフラの直面する脅威を本当の意味で監視・対応できるようになります。