コンテナセキュリティのSysdigのCEOに、オープンコアベンダーとは異なる戦略について訊いた

クラウドネイティブの現在の隆盛の流れのきっかけを作ったのは、Dockerによるコンテナであることに異論をはさむ方はそんなにいないだろう。そしてその流れが、オーケストレーションを行うKubernetesがGoogleからファウンデーションをベースにしたオープンソースプロジェクトに移行し、AWS、Google、Microsoftのパブリッククラウドベンダー3社が素早く対応した時からさらに勢いを増した。このようにして本格的なクラウドネイティブが始まったというのは定説だろう。

しかし同時にセキュリティに関しては早い時点で足らない部分が指摘され、トラディショナルなセキュリティベンダーが埋められない穴を新興のセキュリティベンダーやオープンソースソフトウェアが埋めることで、セキュリティに関するエコシステムが急速に拡大したとも言える。

Twistlock、Aqua Security、NeuVector、Tufinなどの多数のコンテナおよびKubernetesに対応した新興ベンダーによるセキュリティソリューションがあふれている現状で、自社のニーズや環境に合ったセキュリティソリューションを選択するのは非常に困難だと言えるだろう。その中でCNCFがインキュベーションプロジェクトとしてホストするFalcoの開発を主にリードするSysdigのCEO、Suresh Vasudevan氏にインタビューを行った。

CEOのVasudevan氏（左）と日本法人の代表、西岡正氏（右）

Sysdigのこれまでを簡単に振り返っていただけますか？

Sysdigの創業者はもともとWiresharkという世界で最も多く使われているオープンソースのパケットアナライザーを作っていたエンジニアです。彼が2015年にトラブルシューティングのためのツールであるSysdigを、オープンソースソフトウェアとして作るところから始まったのです。

その時に多くのソフトウェアがモノリシックなものからマイクロサービスなものにシフトする中で、コンテナが最も重要なビルディングブロックになると思ったわけです。そしてKubernetesが出てきた時にこれがオンプレミスからパブリッククラウドまで広く使われるようになるという認識を持ったという背景があります。

そしてそのテクノロジーが企業の中で拡がっている場合、一つのチームがそれに取り組んでアプリケーションを開発し、徐々にそれが社内に拡がっていくという流れになるわけです。それが企業の中のクラウドネイティブなチームとして企業を変革していくことになります。

Sysdigの顧客であるBank of New York Mellon（BNY）を例に挙げましょう。BNYは社内のクラウドネイティブなプラットフォームとして、App Engineというアプリケーション開発のベースとなるフレームワークを作っていますが、その上でどれだけのアプリケーションが開発され、本番環境で実行されるのか？　これをKPIとして評価しています。その時に単にクラウドネイティブになるだけではなく金融の世界で要求されるセキュリティやコンプライアンスなどに適合しているか？　この点についても同時に評価されるわけです。それは金融業界では当たり前のことで、そのアプリケーションがモノリシックかマイクロサービスかは関係ありません。つまりクラウドネイティブであると同時に、セキュアで信頼のおけるサービスを実装する必要があります。

Sysdigであればクラウドネイティブなアプリケーションをセキュアにすることができると？

そうです。BNYにとってこれまでのツールでは、コンテナベースのアプリケーションをセキュアにすることはできないということが明らかになりました。コンテナの中で何が行われているのか？　従来のツールではこれを検知できませんし、Kubernetesで動いているPodは従来のファイアウォールでは保護できません。Podがアクセスするファイルの特権の管理も従来のファイル管理システムでは対応できないのが実情です。

モノリシックなシステムはOSなどのインフラストラクチャーがあまり変わらずに安定していたと言えますが、Kubernetesの世界では必ずしもその通りではないのです。あるPodがどの仮想マシンで実行されるのか、それを予め特定することはできません。Sysdigが行ったコンテナの利用に関する調査レポートによれば、約50％のコンテナは5分程度の実行時間しかありません。つまり何か間違ったことが起こったとしても、そのコンテナはすでに終了しているということになります。

ゴールドマンサックスやBNYなどの場合、単にコンテナの中をチェックするだけではなく、実際に情報漏えいなどが起こった時にそれを包括的にチェックするフォレンジックの機能が必要になります。その意味でイメージスキャンニングだけではなくモニタリングの機能を使って、実際にその時に何が起きたのか？　これを確認する機能が使われています。

クラウドネイティブなアプリケーションでは中が見えないこと、実行時間が短いこと、コンテナが実行されるハードウェアや仮想マシンが一定ではないことなどから、新しいツールが必要となったわけです。

参考：Sysdigによるレポート：Sysdig 2019 Container Usage Report: New Kubernetes and security insights

開発の際のイメージスキャンニングだけではなく運用時のモニタリングもSysdigで可能になるわけですか？　そうするとAPM（Application Performance Monitoring）などとも重なる機能ですね。

そうです。今度は運用の面からみた時の話をしましょう。運用を行う場合、重要になるのはシステムがどのように動いているのかを判断するためのシステムに関するメトリックスデータが必要な点です。しかしそれだけではアプリケーションのどの部分が性能に影響しているのかを判断することはできません。非常に多くのコンテナが関係しているシステムでは、全体の速度を見るだけでは性能の遅延の原因を特定できません。

そこで必要となるのは、トレーシングです。どのコンテナのどの部分で何が起きているのかを知る必要があります。そして最後にこれも重要な部分ですがログがあります。これは特にシステムのログについては何か異常なことが起こっているかどうかを判断する目安になります。メトリックス、トレーシング、そしてログがすべて必要になるわけではありませんが、この3つを組み合わせることでシステム全体の運用を行うためのデータと言えると思います。

その中でSysdigは、メトリックスとシステムのログに注力しています。実はインフラストラクチャーがあまり変化しないようなシステムであれば、アプリケーションモニタリングは魅力的なソリューションだったと言えるでしょう。なぜならアプリケーションの内部で何が起こっているのかを明らかにすることには大きな意味があったからです。

しかし今や、Kubernetesの登場によってインフラストラクチャー自体がダイナミックに変化するようになりました。なのでアプリケーション自体のモニタリングだけではなく、ダイナミックなインフラストラクチャー、つまりKubernetesのモニタリングが重要になってきているのです。事実、AppDynamicsを持つCiscoですら、Sysdigのソリューションを顧客に紹介しているくらいですから。

Sysdigが特徴的なのはSysdigというオープンソースソフトウェアだけではなくて、PrometheusやFalco、Anchoreという他のオープンソースソフトウェアと組み合わせてソリューションを構成しているところだと思います。一般的なオープンコアのビジネスとだいぶ異なるのはなぜですか？

Sysdigのプラットフォームは多くのOSSで構成されている

Sysdigは一つのオープンソースソフトウェアから始まりましたが、それをベースにしてそこに付加価値を付けて、例えばエンタープライズ版として販売するというやり方を採っていません。SysdigのDNAにオープンソースソフトウェアは存在していますが、オープンソースソフトウェアはあくまでもビルディングブロックとして使っています。多くのオープンコアの企業は無償のオープンソースソフトウェアを一つだけ作って、それに付加価値を付けることでマネタイズしています。しかしSysdigにとっては、SysdigもFalcoもPrometheusも全体のソリューションを作るためのブロックなのです。SysdigやFalcoを組み込んで価値を提供するという姿勢なので、例えばよそのセキュリティベンダーがFalcoを組み込んで使うソリューションを提供することになっても、それは歓迎すべきことだと思います。

つまりFalcoが別のセキュリティベンダーのソリューションになっても問題ないと？

そうです。その結果Falco自体が進化して良いソフトウェアになるのであれば、それを妨げる理由はありません。同じように我々もモニタリングではPrometheusを使っていますし、コミュニティに積極的に還元するようにしています。

最後になりますが、オープンソースソフトウェアがパブリッククラウドベンダーによってフリーライドされているという論争が起きていますが、それに関して何かコメントは？

そもそもソフトウェアをオープンソースとして公開するのであれば、作り手の側が想定しないような使い方やユーザーが現れるということを想定するべきだと思います。最初はオープンソースにしておいて思ったようにならないからと言って、後から変えるのであれば、最初から公開しないほうが良いですね。そこまで含めてオープンソースソフトウェアにするという決断をするべきです。

我々もFalcoをオープンソースソフトウェアとして公開する際には、8週間くらいさまざまな議論を交わしました。Sysdigのエグゼクティブの中でもさまざまな意見がありましたが、最終的にはFalcoはオープンソースプロジェクトとしてCNCFにもインキュベーションされることになりました。我々の判断は間違ってないと思います。

モノリシックなシステムからコンテナベースのシステムに至る変遷や、クラウドネイティブなシステムにおける開発から運用に至るまでのセキュアなコンテナ実行環境の必要性など、IT業界のベテランとして鋭い考察をしてくれたVasudevan氏だった。オープンソースのライセンスに関する論争については、オープンコアを標榜する企業とは一味違うコメントをしてくれた。なお日本でのディストリビューターとなったSCSKについては「企業向けのパートナーとして信頼を置いている」とコメントし、日本市場での成長に意欲を見せていた。