本文の内容は、2021年5月11日に Sysdig CTO Loris Degioanniが投稿したブログ(https://sysdig.com/blog/aws-fargate-runtime-security-ptrace-ld_preload)を元に日本語に翻訳・再構成した内容となっております。
Fargateは、AWSユーザーに大きな価値を提案しています：仮想マシンのことは忘れて、コンテナをプロビジョニングするだけです。アマゾンが基盤となるホストの面倒を見てくれるので、ユーザーはLinuxインスタンスのメンテナンスやアップグレードの代わりに、ソフトウェアの開発に集中することができます。Fargateは、小さなメンテナンスオーバーヘッド、攻撃対象を狭め、きめ細かな価格設定など、多くのメリットをもたらします。
しかし、他のクラウド資産と同様に、AWS Fargateのタスクを放置しておくと、厄介なことになります。漏洩した場合、誰かがインフラをクリプトマイニングに使用した後に莫大な請求書を受け取ることになるかもしれません。あるいは、攻撃者がクラウドのラテラルムーブメントを実行して、データに完全にアクセスする可能性もあります。
このような問題を検出するには、従来のインフラでアプリケーションを実行する場合とまったく同じように、Fargateワークロードのアクティビティを深く可視化する必要があります。
残念ながら、OSへのアクセスができないため、Fargateでそのようなレベルの可視性を得ることは非常に困難です。幸いなことに、Sysdigはこの問題に対する完璧なソリューションを提案しています。
しかし、ソリューションについて話す前に、問題について説明しましょう。
現在のディープインストルメンテーションのアプローチ
商用、オープンソースを問わず、十分な粒度とコンテナへの対応を備えたランタイムセキュリティ製品を実行する場合、ptrace、LD_PRELOAD、カーネルインストルメンテーションの3つの主要なインストルメンテーション技術のいずれかを採用することがほぼ確実です。これらの技術は、システムの活動（ファイルI/O、ネットワークなど）を細かい粒度（ディスクへの単一アクセス、ネットワークのペイロードの内容など）で観察することを可能にし、真のセキュリティに必要な技術です。
これらの技術を比較する際には、「精度」と「オーバーヘッド」という2つの重要な要素を考慮する必要があります。ここでは、3つの技術について詳しく説明し、これらの要素に関してどのように比較するのかを見ていきましょう。
1. LD_PRELOAD
LD_PRELOADは、環境変数LD_PRELOADを使用して、オペレーティングシステムに異なるバージョンのlibcダイナミックライブラリを読み込むように指示する手法です。Libcは、open()やconnect()などのカーネル関数を呼び出すために、大半のプログラムで使用されています。LD_PRELOADでロードされるバージョンには、これらの関数のすべての呼び出しとそのパラメータを記録するための追加のインスツルメンテーションが含まれている場合があります。LD_PRELOADは比較的効率的ですが、正確ではありません。それは、goで書かれたものなど、多くのプログラムがlibcのダイナミックライブラリを使わず、直接カーネルを呼び出しているからです。LD_PRELOADは、このような種類のプログラムには全く気づかないでしょう。さらに、LD_PRELOADはユーザーレベルの技術であるため、libcを使わずにシステムコールを直接呼び出すような、やる気のある攻撃者には騙されてしまいます。
最後に、システムライブラリの置き換えはかなりリスクが高く、計測対象のアプリケーションに深刻な安定性に関する問題を引き起こす可能性があります。
2.ptraceとその仲間たち
ptrace は、Linux カーネルが提供する最も高度で複雑な機能の 1 つです。ptraceは、適切な権限を持つプロセスが、他のプロセスを一時停止したり、調査したり、制御したりすることを可能にします。また、この文脈では、ptraceという用語を使用する場合、inotifyやfanotifyのような他のユーザレベルのイントロスペクション技術も含まれることに注意する必要があります。これらは、ptraceと同じ特権要件とオーバーヘッドプロファイルを持っています。あなたが日常的に使用しているいくつかのツールは、ptraceに基づいています。例えば、GNUデバッガのgdbがその一つです。ptraceと他の類似した技術は非常に正確ですが、効率的ではありません。ptraceが正確なのは、言語やスタックに依存しないからです（つまり、Goプログラムの活動を見ることができるのです）。また、情報はオペレーティングシステムのカーネルによって生成され、カーネルは少なくとも簡単には騙されません。しかし、これらの技術はすべて、データを収集プロセスに渡すために複数のコンテキストスイッチを必要とするため、非常に遅いものとなっています。
何かが遅すぎる場合、解決策はオーバーヘッドを減らすためにより少ないデータを収集することですが、これでは精度が落ちてしまいます。したがって、ptraceは遅すぎるか、あまり正確でないかのどちらかです。
3. カーネルインスツルメンテーション
この技術は、カーネルモジュールに基づいた伝統的な(そしてより侵襲的な)方法でカーネルに降りていきます。あるいは、カーネル内でコードを安全に実行できる仮想マシンをベースにしたeBPFのような、よりモダンで侵襲性の低い方法を使用します。カーネルインスツルメンテーションは、システムアクティビティを収集するための最も効率的で正確な方法です。効率的なのは、カーネル内のアクションを収集することで最も低いオーバーヘッドが保証されるからです。正確なのは、ご存知のように「カーネルは決して嘘をつかない」からです。
このような理由から、Falco、Sysdig Secure、Sysdig Monitorはこの技術に基づいています。精度と性能の両面で、他のどの手法よりも劇的に優れています。
Fargateの問題点
Fargateのインスツルメンテーションの問題点を簡単にまとめると、ホストへのアクセスができないため、カーネルのインスツルメンテーションができず、LD_PRELOADとptraceベースのアプローチのどちらかを選択しなければなりません。その結果、精度、性能、またはその両方を犠牲にしなければなりません。果たしてそうでしょうか？Sysdigの高度なFargateインストルメンテーションの紹介
Sysdig SecureとSysdig MonitorのFargateサポートのリリースに伴い、Sysdigはオープンソースのpdigフレームワークの上に構築され、サーバーレスアプリケーションの性質に焦点を当てた強力な最適化を追加した新しい特許技術を提供しています。カーネルキャプチャーと同等のデータ精度、あらゆるタイプの実行ファイル（Goプログラムを含む）のフルサポート、従来のコンテナ化されたインフラで経験するのと同等のオーバーヘッドを提供できるものを目指しました。その結果は？数字で語ってもらいましょう。下の図は、I/Oインテンシブなワークロード（100k IOPS以上）をFargateコンテナで実行するのにかかる時間を、完全な精度で示しています（すべてのI/O操作が記録されています）。
このような厳しいシナリオでも、カーネルインスツルメンテーションによってインスツルメンテーションされたアプリの速度低下が最小限に抑えられていることがわかります。一方で、少なくとも完全な精度では、ptraceの影響は非常に大きく、4倍以上の速度低下が見られます。
Sysdig advanced Fargate instrumentationは、カーネルインスツルメンテーションのオーバーヘッドに近い値にインスツルメンテーションのオーバーヘッドを抑えることに成功し、同時にすべてのI/O操作をキャプチャし、Goなどの言語をサポートしています。