Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2021年11月15日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/intro-runtime-security-falco/）を元に日本語に翻訳・再構成した内容となっております。
クラウドネイティブなワークロードにランタイムセキュリティを実装する際の課題を克服するために、Falcoをどのように使い始めるかをご紹介します。
コンテナやクラウドを導入している方は、デプロイの自動化やスケーラビリティの向上などのメリットを享受していることでしょう。しかし、セキュリティに関しては、これは新しいルールを持つ全く新しい世界であり、従来のセキュリティツールでは追いつくことができないと感じているかもしれません。新しいパラダイムであるクラウドネイティブ環境には、新しいクラウドネイティブツールが必要です。
ではランタイムセキュリティに焦点を当てていきましょう。
コンテナは軽量で、同じホストマシン上で何百、何千ものコンテナを実行するのが一般的です。また、コンテナはブラックボックスであり、従来のホストベースのツールでは見えないことが多々あります。
最初の苦労は、このような事に悩みます。"コンテナ内でランタイム中に何が起こっているのか、どうやって知ることができるのか？" 結局のところ、見えないものをどうやって守るのか？
また、不審な動きを検知した場合、疑問に思うことがあります。「どうやって適切な状況を把握して対応すればいいのか？」例えば、そのアクティビティはどのコンテナで行われたのか？どのようなワークロードに関連しているのか？そして、そのイベントに対応する適切なチームは誰なのか？
Falcoのようなクラウドネイティブツールは、個々のコンテナが行っていることをすべて見ることができ、"おーい、ちょっと、ちょっと、このredisコンテナはネットワークの外に接続を繋いじゃダメなんじゃない？"とか、"なぜこのApacheサーバーでファイルが変更されたの？"といった疑わしい動作に簡単にフラグを立てることができます。
ここでは、ランタイムセキュリティについて簡単に紹介し、Falcoがどのように魔法をかけているか、Falcoを使い始めるのがいかに簡単かを明らかにします。
脆弱性が本番環境に到達しないようにブロックすることは、非常に心強いことだと思います。このような脆弱性の予防的発見は、通常、イメージスキャンツールで実現されます。
スキャンの結果がきれいであれば、安全だと思うかもしれません。結局のところ、"脆弱性のあるアプリケーションをデプロイしていないのに、どうやって攻撃されるのか？"ということになります。
しかし、すべての脆弱性が知られているわけではありません。アプリケーションが本番稼動した後に脆弱性が公開された場合、あなたはまだ知らないうちにリスクにさらされているかもしれません。さらに、すべての脆弱性をすぐに修正できるとは限らないので、それまでの間、既知の脆弱性を持つシステムを注意深く監視する必要があるかもしれません。ランタイムには様々なことが起こり得ます。
コンテナのランタイムセキュリティに焦点を当てると、いくつかのセキュリティ上の脅威は、その性質上、ランタイム中にのみ発生します。これには以下が含まれます。
ランタイムセキュリティは、コンテナセキュリティの中でも最も複雑な側面の1つです。これは、使用するコンテナアプリケーションスタックの種類によって異なる、複数の動作が関係しているためです。しかし、ほとんどの場合、ランタイムセキュリティは、以下のものを保護することに基づいています。
これらすべてを保護するために、最も人気のあるOSSでクラウドおよびコンテナセキュリティに関するツールはFalcoです。Falcoは、クラウドネイティブにおけるランタイムセキュリティプロジェクトであり、デファクトのKubernetes脅威検出エンジンです。 Falcoは、インキュベーションレベルのプロジェクトとしてCNCFに参画した最初のランタイムセキュリティプロジェクトです。 Sysdigは2016年にFalcoを作成しました。これは、予期しないアプリケーションのビヘイビアを検出し、ランタイムにおいて脅威を警告するように設計されています。
Falcoは、カーネルのシステムコールを分析することで、コンテナ、ホスト、クラスターのアクティビティを深く可視化します。また、Kubernetes APIの監査イベントなど、他のデータソースも活用します。同様に重要なのは、FalcoがKubernetesアプリケーションのコンテキストを調査結果に加えることで、DevOps、セキュリティ、クラウドの各チームが、誰がどこで何をしたのかを正確に理解できるようにすることです。
Falcoのアーキテクチャ：複数のイベントソースがあり、イベントはポリシー評価者を通過し、アラートが生成され、通知チャネルを介して送信される
Falcoの仕組みを理解するには、まず3つの主要なコンポーネントを見てみる必要があります。
Falcoのアーキテクチャーでは、システム情報を収集するカーネルモジュールとeBPFプローブがあります。そして、いくつかのライブラリが、Falcoに到達するまで、それらのイベントを処理します。
Falcoの特徴のひとつは、監視専用のツールであることです。1つまたは複数のチャンネルにアラートを送ることができますが、それだけでは何のアクションも起こせません。アラートチャンネルの例は以下の通りです。
可能なFalco出力のリストは、別のオープンソースツールであるFalcosidekickによって拡張されます。詳しくは、Extend Falco outputs with Falcosidekickをご覧ください。
Falcoはルールを使って、与えられた条件のもとで疑わしい動作を検出します。たとえば、コンテナ内のbashは異常なことかもしれませんが、アラートをトリガーする条件（この場合はproc.nameがbashであること）にのみ注目する必要があります：
- rule: Detect bash in a container desc: You shouldn't have a shell run in a container condition: container.id != host and proc.name = bash output: Bash ran inside a container (user=%user.name command=%proc.cmdline %container.info) priority: INFO
このように、ルールに簡単な言葉を使うだけで、このような動作を簡単に検出できることがわかります。Falcoのルールについてもっと知りたい方は、ドキュメントのルールを見てみてください。
このルールがイベントを検出すると、出力オプションを設定している場合は、次のようなメッセージが表示されます。
20:07:06.837415779: Notice A shell was spawned in a container with an attached terminal (user=root container=1dab04047700 shell=bash parent=runc cmdline=bash terminal=34816 container_id=1dab04047700 image=docker.io/falcosecurity/falco) container=1dab04047700
これで完了です。ランタイムコンテナのアクティビティを確認し、潜在的なセキュリティイベントを検出することができました。
"わかった、わかった、Falcoは素晴らしい" - あなたの声を聞きます - "でも、このプロジェクトはどれくらいしっかりしているの？"
これは妥当な質問です。結局のところ、あるソリューションにコミットして、しばらくしてから別のものに移行したいと思う人はいないでしょう。ここでは、いくつかの興味深い事実を紹介します。
Falcoは、Linux Foundationの一部であるCNCF傘下のオープンソースプロジェクトです。
Falcoは広く採用されており、CNCFに参加して以来、プロジェクトの人気は4倍になっています。Falcoのイメージは3000万回以上ダウンロードされています。
さらに、Falco の github レポをフォローしているユーザーの数は、インキュベーション時の 2 倍になっています。
Falcoのエコシステム内の他のプロジェクトも繁栄しています。例えば、コミュニティによって開始されたFalcosidekickは、300万ダウンロードを達成したばかりです。
採用は至る所で行われており、Falcoは公式のCKS試験のカリキュラムの一部になっています。
Falcoの技術的なアーキテクチャは、最新の環境のニーズを満たすように慎重に設計されています。基盤となるeBPF技術により、Falcoはパフォーマンスにほとんど影響を与えず、極端なストレステストでもCPU使用率は他の製品の半分程度です。
Falcoは、ハイパフォーマンスな環境にも導入されています。ユーザーの一人であるskyscanner氏は、「K8sクラスターにデーモンセットとしてFalcoを導入しても、サービスのパフォーマンスには何の悪影響も出ていない（信じてほしい、本当に壊そうとしたんだ）」と報告しています。
Falcoのウェブサイトを見れば、エンドユーザーのリストにビッグネームが並んでいることがわかります。
Falcoのユーザーには、shopify、skyscanner、Frame.io、GitLabなどが名を連ねています。
そして、私たちにとってケーキの上のアイシングは、Gartnerに認められたことです。ガートナーのアナリストは、Falcoを使用する理由の中で、"Falcoは、Kubernetesのコンテキストアウェアネスにより、アプリケーションのデプロイメントにおける異常なビヘイビアの検出を可能にする "と指摘しています。"[1]
Falcoは、活発なコミュニティを持つ強力なプロジェクトであり、ランタイムコンテナのセキュリティニーズを満たすための重要な候補であると考えるべきでしょう。
LinuxマシンにFalcoをインストールするには、カーネルモジュールをインストールして、次のように実行するだけで簡単です：
apt-get install -y falco
これだけです。
しかし、クラウドネイティブな世界では、ホストに直接アクセスできない場合や、他のアプリケーションと同じようにFalcoを導入したい場合があります。
ここでは、KubernetesのパッケージマネージャーであるHelmを使って、KubernetesクラスターにFalcoをインストールする方法と、利用可能なルールをカスタマイズする方法について説明します。
心配しないでください。私たちがサポートします。
指示に従ってMinikubeをインストールすれば、あっという間にシングルノードのKubernetesクラスターができあがります。
Minikubeを起動するには、次のようにします：
$ minikube start
そして、起動していることを確認するために簡単なテストを行います：
$ minikube kubectl -- get nodes NAME STATUS ROLES AGE VERSION minikube Ready control-plane,master 6m18s v1.22.2
ここからは、 kubectl クライアントがローカルにインストールされていると仮定して、コマンドを kubectl get nodesとするだけです。これらのコマンドを簡略化するためのエイリアスの作成方法については、minikube kubectl documentationを参照するか、ここにアクセスして kubectl をあなたのマシンにインストールしてください。
そのためには、Helmがインストールされていることを確認します。
ここでは、コミュニティでサポートされているチャートを使ってFalcoをインストールします。
まず、 falcosecurity のチャートのリポジトリを追加し、アップデートします：
helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update
さて、いよいよ helm install コマンドを使ってFalcoをインストールします：
helm install falco falcosecurity/falco
コンテナが起動するまで数秒待ち、Falcoポッドを特定し、コンテナのログを見てみましょう：
$ kubectl get pods `NAME READY STATUS RESTARTS AGE `falco-467d7 1/1 Running 0 4m13s $ kubectl logs falco-467d7 ... Wed Nov 3 15:05:17 2021: Falco initialized with configuration file /etc/falco/falco.yaml Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.yaml: Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.local.yaml: Wed Nov 3 15:05:17 2021: Starting internal webserver, listening on port 8765 ...
無事にFalcoがデプロイされたようですね
さて、Falcoがデプロイされて動作しているので、不審な活動を検出できるかどうか見てみましょう。
コンテナは対話的にアクセスされることを想定していないため、コンテナが危険にさらされていることを示す最大の赤信号の1つは、ターミナルシェルが起動したときです。これが起こる正当な理由はありますが、通常はトラブルシューティングの作業に限られます。
Falcoには、このようなシナリオを検出するためのルールがデフォルトで有効になっています。この場合、関連するルールは "Terminal shell in container" です。
先ほどデプロイしたのと同じ falco Podを使って、その中でいくつかのコマンドを実行してみましょう。
$ kubectl exec -it falco-4gsbr -- /bin/bash root@falco-4gsbr:/#
ここでは、クラスターに確実に存在すると思われるfalcoを使用しています😉。
falcoのログを確認すると、警告が表示されます：
$ kubectl logs falco-4gsbr ... 16:37:58.199209616: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd shell=bash parent=runc cmdline=bash terminal=34816 container_id=b1cfe2fbfcdd image=falcosecurity/falco) k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd ...
イベントがトリガーされたポッドとネームスペースについて、Falcoがコンテキスト情報を提供していることに注目してください(k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd)。
Falcoが動作するようになったことで、いろいろな楽しみ方ができるようになりました。
例えば、ログとは別のチャンネルでアラートを送ることができます。このような効果を得るためには、falcosidekickプロジェクトをチェックするとよいでしょう。
で旅を続けましょう：
また、Falco プロジェクトに参加したい場合は、Falco.org にアクセスしてください：
オープンソースのソリューションは、お客様のチームによるDIYの努力を必要とします。ツールを完全にコントロールすることができますが、すべてのコンポーネントの設定、構成、保守にも責任があります。
迅速な導入、低い管理費、高いスケーラビリティ、カスタマーサポート、その他のプレミアム機能を必要とするチームは、商用版の製品を好むかもしれません。
商用版の製品は、ランタイムセキュリティだけに焦点を当てるのではなく、複数のセキュリティユースケースに同時に対応することで、付加価値を高めています。
例えば、商用版の製品は、クラウドの設定ミス、ランタイムセキュリティイベント、およびイメージスキャンの結果をチェックできる単一のガラス窓を提供することができます。これらの情報が同じ場所にあることで、異なるダッシュボード間を行き来する必要がなくなり、インシデント対応やフォレンジックをより効率的に行うことが可能になります。
商用版の製品は、インフラのセキュリティ確保を容易にするだけでなく、クラウドのセキュリティ態勢を長期的に把握することも目的としています。
多くのセキュリティ製品は、コンプライアンス要件をすぐに満たせるように作られています。アプリケーションライフサイクルのすべての側面を把握することで、市販のツールは、コンプライアンスから外れている場所を教えてくれると共に、改善策を提示してくれます。
Sysdig SecureがFalcoのセキュリティを拡張し、アプリケーションライフサイクル全体の包括的なセキュリティワークフローを提供する方法をご覧ください。
Falcoは、コンテナやKubernetesにランタイムセキュリティを実装するための堅実なオープンソースソリューションです。
Falcoのクラウドネイティブな設計により、最新のアプリケーション環境で発生するセキュリティイベントを迅速かつ効果的に解決するために必要なコンテキストを提供することができます。
Falcoの詳細を知りたい方は。
Sysdig Secureでは、他のオープンソースプロジェクトとともに、アウトオブボックスのルールでFalcoを拡張し、Kubernetesのセキュリティへの取り組みと管理をさらに容易にしています。30日間の無料トライアルに登録して、ご自身の目で確かめてください。
Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドサービスを自信を持って実行するためのセキュリティを提供します。Sysdigでは、ビルドパイプラインの保護、ランタイム脅威の検出と対応、コンプライアンスの継続的な検証、クラウドインフラストラクチャーとサービスの監視とトラブルシューティングを行うことができます。今すぐお試しください！
[1] Gartner, "Open-Source Options for Threat Detection and Incident Response", Anna Belak and Eric Ahlm, 1 December 2020.
