Distrolessのコンテナイメージ削減技術によるクラウドセキュリティの強化｜トレンドマイクロ

2013年にサービスを開始したDockerによって、開発におけるコンテナの扱いは大きく変化しました。さらにDocker Hubによって、コンテナイメージの配布法にも変化が生じました。コンテナにコードをデプロイする開発においては、頻繁に使用される環境設定や機能を再構築する必要がないように、Docker Hub上で配布されているベースイメージを利用する場合が多く見られます。実際に、Docker Hubで公開されている有名なイメージの中には、このパターンを踏襲したものがあります。例えば、インメモリ型ストレージサーバ「redis」の公式イメージでは、Linuxディストリビューション「Debian」の公式イメージがベースの1つに採用されています。こうしたベースイメージの利用は一見すると良いやり方にも見えますが、クラウドセキュリティの観点に立つと、個々のイメージが持つデータ領域の安全性を検証する必要性が生じることもあり、開発者が必ずしも踏襲すべき習慣であるとは言えません。多くの場合、公式イメージは開発者コミュニティによって運用されています。開発者がベースとして用いるオペレーティングシステム（OS）のイメージを決定すると、ほとんどのアプリケーションイメージはそのベースイメージを土台に含む形で開発されます。このことは、ベースイメージに存在する脆弱性やセキュリティ不備は、それを使用するアプリケーションイメージ側にも引き継がれることを意味します。

本ブログ記事では、コンテナイメージのセキュリティを最適化する上で有力なDistrolessの技術について解説します。さらにその代替手法として、コンテナイメージが抱える容量を削減し、かつクラウドネイティブアプリケーションへの攻撃対象領域（アタックサーフェス）を縮小できる方式についても提起します。

現在の業界における技術的動向

最近、情報セキュリティ分野では、ソフトウェア部品表（SBOM：Software Bill of Materials）という概念が注目を浴びるようになりました。SBOMは、特定のコンテナやファイルシステムにインストールされている全パッケージ情報を一覧化したものです。SBOM情報を生成するツールとして、最近では業界標準で利用されるようになった「Syft」などが挙げられます。

今回は実際にSyftを用いて、Debianの公式イメージに含まれるパッケージの一覧情報を抽出しました。

図1： Debianの公式イメージに含まれるパッケージ一覧をSyftによって抽出（図中に示されるパッケージは一部のみ）

図1を見ると、このイメージには96個のパッケージが含まれることが分かります。さらに、Syftと同様によく知られたツールである「Grype」を用いることで、Syftが生成したSBOM情報をさらに解析して、イメージ内の脆弱性を検出することも可能です。

図2： Debianの公式イメージに含まれる脆弱性の一覧をGrypeによって抽出（図中に示される脆弱性は一部のみ）

Debianをベースとするイメージの使用によって生じるリスクの規模について、簡潔な見方をするならば、パッケージ数が多いほど攻撃対象領域も広がると言えるでしょう。こうしたリスクに加えて、所要メモリや処理帯域が増加することも相まって、多くの開発者がDebianベースのイメージからAlpineベースのイメージに移行するようになりました。「Alpine Linux」は標準Cライブラリ「musl libc」とコマンド集約プログラム「BusyBox」から構成されたLinuxディストリビューションであり、新規参入者にとっては軽量でセキュリティ志向の強い選択肢の1つと言えるでしょう。

Alpine Linuxを用いる利点は下図からも確認できます。

図3：デフォルトの Alpineイメージに含まれるパッケージが比較的少ないことを示すSyft解析の結果

さらに本調査の時点で、Grypeで検知された脆弱性は1件もありませんでした。

図4：軽量なセキュリティ志向型LinuxディストリビューションであるAlpine Linuxを使用

Alpine Linuxがもたらすセキュリティ上の恩恵は大変有意義なものです。また、これまでにも適宜アップデートが行われてきました。

現状の課題

これまでDebianやAlpineなどのベースイメージが内部に持つ脆弱性について議論してきましたが、コンテナ全体に潜む脆弱性は、ベースイメージ由来のものに限定されません。開発者がコンテナ内に追加実装したアプリケーションにも、新たな脆弱性が隠れている可能性はあります。問題点について明確にするため、ここではコンテナ内のアプリケーションに脆弱性があり、その脆弱性を突いて攻撃者はコンテナ環境でサポートされているコマンドやコードをリモートから実行（RCE：Remote Code Execution）できる状況を、可能性の1つとして想定します。

上述の脆弱性を持ったアプリケーションがDebianのイメージをベースに動作している場合、図2で挙げたパッケージ管理ツール「APT（Advanced Packaging Tool）」のように、Debian用ベースイメージに含まれる機能が、攻撃者に不正利用されるケースが考えられます。この点については、Alpineベースの公式イメージにおいても大差はありません。こちらでも、wgetなどのUNIXコマンドを1つの実行ファイルに集約した「BusyBox」や、パッケージ管理ツール「APK（Alpine Package Keeper）」をはじめとする強力な機能が、ベースイメージ内に含まれているためです。

攻撃者は脆弱性を常に探索して利用しようと画策しているため、攻撃の継続や高度化を許してしまうような要素は可能な限り取り除いておくことが望まれます。

攻撃者側の視点に立つと、公開されたコンテナのシェルに不正アクセスする上で、パッケージ管理ツールは突破すべき壁であり、特に重要な攻撃目標であると言えます。しかし、注意を要するツールはこれだけではありません。ベースイメージにもよりますが、攻撃に利用されかねないLinuxのネイティブツールが相当数存在することが、攻撃対象領域の割り出し調査によって判明しました。ベースイメージからこうした一部のツールを排除することで、より一層のセキュリティが確保されると考えられます。

こうした課題への対処法として、上述したリスクの高いツール類をまず特定し、それに対応するバイナリファイルをビルド時に除去しておくことが挙げられます。しかし、このやり方にも懸念点はあります。まず、除去対象のツールを全て洗い出すには相応の労力が必要になります。さらに攻撃者側も依然として、残されたツールを最大限に不正利用するために想像力を駆使して策を講じてくるでしょう。

そうしたツールの分かりやすい一例として、完全版Linuxディストリビューションを含む全てのコンテナのベースイメージに含まれるコマンド「base64」が挙げられます。このコマンドは、データ転送時のエンコードまたはデコードに使用されます。実際に確認されたクラウド型の攻撃では、まずBase64でエンコードされた多数の不正なツールが標的環境に送りつけられます。続いて、標的環境ではコマンド「base64」がすでにインストールされている前提の元で、Base64によるデコード処理が行われ、マルウェアなど不正活動に使用するためのツールをダウンロードまたはドロップし、最終的にコンテナの不正利用に発展します。

図5： Linuxネイティブのコマンドによって攻撃が展開する様子を示す分析ツール上の画面

また、クラウドサービスプロバイダー（CSP）が提供するサービスの中には、コンテナや小型の仮想マシン（VM）で稼働するものがあります。こうしたコンテナやVMについても、その多くが必要最小限以上のパッケージを抱えている点で、問題があります。

公開されたコンテナ内で稼働するアプリケーションの不正利用が可能になった時点で、サイバー攻撃の準備は整います。そのアプリケーションのインフラがオンプレミスでもCSPでも、攻撃者はコンテナ内のツールを不正に活用してさらなる攻撃を展開しようと目論むでしょう。

セキュリティ課題への対処法

まず明らかなこととして、攻撃対象領域を狭めるべきです。近年、攻撃者は「Living Off the Land（環境寄生）」の攻撃戦略に則り、侵害する環境に標準で存在するツールを自身の不正活動に悪用します。ツールを最低限にすることで、攻撃者は自身の不正活動に必要なツールを自身で持ち込む必要が生じます。また、「Log4Shell」脆弱性を引き合いに出すまでもなく、イメージに含まれるツールすべてについて、それに起因する脆弱性のリスクがついて回ることになります。

これに関連し、Googleは、アプリケーションと必要なランタイム依存のみを含むDistrolessと呼ばれるイメージを作成しました。標準的なLinuxディストリビューションと異なり、Distrolessのイメージには管理用のツールやシェル、その他のプログラムが含まれていません。

図6：Google DistrolessのDebianイメージに含まれるパッケージ数が少ないことを示すSyft解析の結果

図7：Google DistrolessのDebianイメージに含まれる脆弱性を示すGrype解析の結果そもそものパッケージが最低限なため、今後の新たな脆弱性についても影響の特定が容易

図8、9のイメージはAmazon Web Service（AWS）によるベースイメージの一種であり、ユーザ自身のイメージを作成するために使用されます。

図8： AWSのベースイメージに多数のパッケージが含まれていることを示すSyft解析の結果

図9：AWSのベースイメージに含まれる脆弱性を示すGrype解析の結果今後の新たな脆弱性については含まれる123のパッケージすべてを把握し確認する必要がある

図10：AWSのNode.js用ベースイメージに多数のパッケージが含まれていることを示すSyft解析の結果

図11：AWSのNode.js用ベースイメージに含まれる脆弱性を示すGrype解析の結果今後の新たな脆弱性については含まれる339のパッケージすべてを把握し確認する必要がある

これらのアプローチは、先に挙げた2つの主要なセキュリティ課題に対処するものです。第一に、イメージ内のパッケージ量が大幅に削減され、アプリケーションの動作に必要なものだけが保持されます。これにより、サイバー犯罪者に狙われる攻撃対象領域が狭まります。第二に、脆弱性の影響が劇的に減ります。現在、そして将来の脆弱性についても、パッケージ数が少ないほどリスクを抑えることができます。以上の結果、より一層セキュアなアプリケーションのデプロイが可能になります。

Distrolessの代替手法

Distrolessを用いた取り組みについて調査したところ、その大半は、主に軽量で高速なコンテナの作成に重点を置いていることが分かりました。多くの場合、コンテナイメージ内に不要なツールやライブラリは見つかりませんでした。中にはスクラッチイメージを使用して、後のマウント用に少数のベースファイルシステムを用意しただけのものも見られました。

今回はDistrolessの代替手法として、「スクラッチイメージ」と「マルチステージビルド」を併用することによって、アプリケーションの動作に必要なバイナリのみを残せる方式について検討しました。スクラッチイメージは、Dockerで構築可能な最小限のイメージです。またマルチステージビルドは、中間イメージや個別のビルドスクリプトを必要としないただ1つの Dockerfile のみで機能します。したがって、この2つの技術を組み合わせることで作成するイメージのサイズを可能な限り制限することができます。

この方式は、アプリケーションを小さな機能に分割してデータを処理する「サーバーレス」の発想とも良く適合します。別の言い方で「個々の機能にはただ1つの目的が存在する」と表現されることもあります。これは確かに本来意図された用法ではありますが、さまざまなユーザによる実践的な使い方とは異なる可能性があります。

コンテナイメージに期待される用法や用途を念頭に置くと、機能や関数の実行にあたっては、スクリプトのインタプリタと、CSP内部で使用するAPI（Application Programming Interface）用バイナリという2要素が必要になります。この前提をもとに、上述したDistrolessの代替手法について検証した結果、コンテナ数も、攻撃対象領域も、CSPのイメージ中に含まれていた脆弱性も、大幅に削減可能であることが分かりました。

結論

Distrolessのコンテナイメージが登場してからかなりの期間が経過しましたが、標準的に使用されるほどの状況には至っていません。コンテナセキュリティに関する調査と分析の成果が少しずつ蓄積されていく中、トレンドマイクロでは今後も技術やノウハウを活かしながら、クラウドインフラのコンテナセキュリティ改善に向けた取り組みを進めていきます。今回の調査では、Distrolessによってどのようにリソースを最適化し、セキュリティ上の課題を解決できるかを示しました。しかし、Distrolessによる取り組みがそれほど浸透していない実情を踏まえ、今回は、スクラッチイメージとマルチステージビルドを併用することで、アプリケーションの動作に必要なバイナリのみを保持できる代替方式について検討しました。この方式を適切に実装することにより、クラウドネイティブアプリケーションを標的とした攻撃対象領域の最小化や、脆弱性のコントロールといった課題に対処することが可能になります。

今回挙げたスクラッチイメージとマルチステージビルドによるコンテナイメージの最適化手法は、クラウドセキュリティの向上を目指す開発者にとって下記のメリットがあります。

アプリケーションを小さな機能単位に分割して、サーバーレス関数によってデータを処理することが基本方針となっているため、サーバーレス環境に適合しやすい
コンテナの容量を大幅に削減できるだけでなく、CSPにより提供されるイメージに含まれていた脆弱性や攻撃対象領域を縮小することができる

参考記事：

Enhancing Cloud Security by Reducing Container Images Through Distroless Techniques
By: Alfredo Oliveira, Raphael Bottino

翻訳：清水浩平（Core Technology Marketing, Trend Micro™ Research）

タグ

Distrolessのコンテナイメージ削減技術によるクラウドセキュリティの強化

執筆者

リソース

サポート

会社概要

リソース

サポート

会社概要

The Americas

Asia Pacific

Europe, Middle East & Africa