脆弱なものをコンテナで実行しても、脆弱なまま

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

暗号化された悪意のあるコードも、依然として悪意のあるコードであることに変わりはない、と言われています。これは私だけの見解ではありません。暗号化によって変わり得るのは、ネットワーク上を転送される際に、セキュリティおよびアプリケーションインフラストラクチャから見えなくなることだけです。

コンテナで稼働するアプリやプラットフォームについても同じことが言えます。アプリに脆弱性があるなら、OS上、仮想マシン内、あるいは現在一般的なコンテナ内のいずれで稼働していても、その脆弱性は変わりません。データセンターで脆弱なアプリは、クラウドでも脆弱です。その逆も同様です。

コンテナは、アプリケーションを魔法のように保護するよう設計されているわけではありません。ネットワーク層で基本的なセキュリティ機能を提供しますが、ネットワークとアプリケーションは別物です。アプリケーションには、コードやインターフェース（API）に加え、必要なプロトコル（HTTP、TCP）やアプリケーションスタックから成る攻撃対象領域があります。IPテーブルにエントリを追加したり、コンテナ環境のイングレスからの受信リクエストだけに制限したりしても、この攻撃対象領域は変わりません。

この点を取り上げたのは、Sonatypeの2017年DevSecOps調査がきっかけです。この調査では、2,200人を超える回答者の88%がコンテナセキュリティの重要性を認識していた一方、セキュリティ製品を活用してコンテナ内の脆弱なアプリケーション、OS、構成を特定している回答者はわずか53%でした。

この統計の最初の2項目であるアプリケーションとOSが目に留まりました。これらは、完全なアプリスタックを構成する要素のうち、場所や運用モデル（クラウド、コンテナ、仮想化など）によって必ずしも変わるわけではないためです。SQLiやXSSの脆弱性があるアプリやAPIは、モデル間を移行したからといって自動的に保護されるわけではありません。その脆弱性はコード内にあります。これは、アプリセキュリティスタックの一部であることに疑いの余地がないプラットフォームについても同様です。Linux上で動作するApacheのHTTPヘッダー処理に脆弱性がある場合、そのアプリを従来のOSベースのモデルからコンテナ化モデルに移行しても、脆弱性は残ります。

アプリスタック全体の脆弱性を継続的に特定することは重要であり、不可欠です。アプリがどこに、どのような形態でデプロイされているかは問いません。

コンテナへ移行する際も、従来型アプリですでに使用しているアプリ保護を引き続き維持することが同様に重要です。Webアプリケーションファイアウォールは、従来型環境やクラウドにデプロイされたアプリと同様に、コンテナにデプロイされたアプリにも有効です。

調査では、回答者が静的スキャンやリアルタイムスキャンのソリューション（SAST、DAST、IAST、RASP）など、その他のセキュリティツールも使用していることがわかりました。Webアプリケーションファイアウォール（WAF）は他のツールよりも広く使用されていますが、SASTとSCA（ソースコード解析）も一般的です。SCAは、デリバリー前に問題を洗い出す静的な手法です。古い話になりますが、lintのようなツールもSCAツールに分類されます。こうしたツールでは、コード同士（およびコードとユーザー）の相互作用によって生じる脆弱性をリアルタイムで明らかにすることはできませんが、メモリリークやクラッシュ、悪名高いバッファオーバーフローにつながる、開発者にありがちなミスの一部を検出できます。

何をお考えかは分かります。こう思っているのでしょう。「Lori、ちょうどStack Overflowの2017年開発者調査結果を読んだところですが、開発者が好む言語ではJavaScriptが断トツの1位です。それにJavaScriptはインタープリター型言語なので、バッファオーバーフローやメモリリークの話はどれも、C/C++でコーディングしていた昔の嫌な思い出にすぎませんよね」

しかし、JavaScriptをはじめとする最新のインタープリター言語も、最終的にはC/C++のような、よりハードウェアに近い言語で実装されています。そして、過去に実証されているように、十分な知識と技術があれば、その事実を利用してシステムを悪用するエクスプロイトを作成できます。

また、それが問題にならない場合でも、どのようなコードにも、使用しているライブラリやシステムコールの誤用に起因し、サーバー側のセキュリティ侵害につながる脆弱性が数多く存在します。最近の調査によると、アプリの80%はオープンソースコンポーネントで構成されています。さらにSonatypeの調査では、オープンソースコンポーネントに関連する、確認済みまたは疑いのある侵害が、2014年から2017年にかけて50%増加したと報告されています。こうしたコンポーネントの多くは、制御が比較的緩く、その言語に精通した開発者も減少しているため、より重大なミスが起こりやすい言語で記述されています。

要するに、どのようなコードにも脆弱性が含まれる可能性があります。そして、コードは、今日のビジネスの顔ともいえるアプリを構成する要素です。そのため、アプリがどこに、どのようにデプロイされていても、スキャンして保護することが重要です。

コンテナでもクラウドでも、従来型環境でも仮想環境でも、すべてのアプリケーションで脆弱性をスキャンし、プラットフォームやプロトコルの脆弱性を悪用する攻撃から保護する必要があります。例外はありません。

アプリケーションは、開発中に徹底的なスキャンとテストを行い、本番環境でも改めてテストする必要があります。どちらも欠かせません。なぜなら、分解の誤謬が示すように、新しいコンポーネントを導入するとベースラインが変化するためです。新たな相互作用によって、これまで発見されていなかった脆弱性が顕在化する可能性があります。

アプリを保護するために、以下をご検討ください。

• 開発時には、コードおよびアプリの分析ツールを活用します。可能であれば、CI/CDパイプラインに組み込んでください。
• 他のコンポーネントやアプリとの相互作用によって問題が顕在化する可能性があるため、本番環境でも再度テストします。
• 常に最新情報を把握してください。対象には、プロトコルとプラットフォームの脆弱性に加え、使用している可能性のあるサードパーティ製ライブラリで発見された脆弱性も含まれます
• Webアプリケーションファイアウォールをアーキテクチャに組み込んでください。ブロッキングモードで使用しない場合でも、プロトコルやプラットフォームのゼロデイ脆弱性、またはライブラリの脆弱性が発見された際に、非常に有用なリソースとなります。

安全を確保しましょう。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事