安全なコンテナイメージレジストリIron Bankの紹介: NECセキュリティブログ

Tweet
Share

2023年6月23日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの森本です。
本ブログでは、安全性の高いコンテナイメージを公開するIron Bank new window [1]について紹介したいと思います。
コンテナ技術では、実行コンテナの雛形となるコンテナイメージに必要なソフトウェアが事前にインストールされています。そのため、既存のコンテナイメージ（ベースイメージ）を利用することで開発コストの削減が期待できます。一方、第三者が作成したイメージを利用する場合、マルウェアや脆弱性のあるコンポーネントを成果物に取り込んでしまうリスクも考えられます。そのため、安全なベースイメージを選択することはコンテナのセキュリティを担保する上で重要なステップといえます。具体的には、ベースイメージの導入前に脆弱性、構成不備、マルウェアの混入などのリスクが対処されていることが理想といえます。しかし、Docker Hub new window [2] のように著名なレジストリで公開されるイメージであっても、これらの要件が十分に満たされていないケースがあります。今回はベースイメージの安全性に関する考え方や、より安全性の高いコンテナイメージを提供する米国防総省のIron Bankについて紹介します。なお、コンテナイメージのセキュリティについては以前の記事[3]でも取り上げていますので、こちらもご参考ください。

Docker Hubで提供されるコンテナイメージの安全性

コンテナイメージが公開されたコンテナレジストリはいくつか存在していますが、ここでは特に著名なDocker Hubを取り上げます。Docker Hubで公開されるコンテナイメージには、表1の通り個人が自由に公開可能なものや、提供元、品質について検証されたものがあります new window [4] [5] [6]。

表1: Docker Hubで公開されるコンテナイメージ

イメージの区分	特徴
Community	不特定の個人によって公開可能なイメージ。
Official	公式コミュニティでレビューされたイメージ。
Verified	提供元が検証されたイメージ。

Communityイメージについては、脆弱性や悪意のあるコンテンツが意図的に組み込まれているケースもあり、利用する際には特に注意する必要があります new window [7] 。一方、Officialイメージは、Dockerfileのベストプラクティス適用、パッチ適用などが実施され、比較的安全性の高いイメージとされています。ただし、非推奨化されているにも関わらずOfficial表記のままとなっているもの（図1）やパッチ未適用の脆弱性が存在するケースも一部報告されています new window [8]。

そのため、Officialイメージであったとしても利用者側においてメンテナンス状況の確認や脆弱性診断の十分な実施が求められる状況といえます。

Iron Bank

Docker Hubよりも厳格なセキュリティ要件が考慮されたコンテナイメージのレジストリとして、米国防総省がホストするIron Bankを紹介します。Iron Bankは、米国防総省や商用ベンダを主な利用者としていますが、アカウント作成した方であればライセンスの範囲で利用することが可能です。
Iron Bankは、利用可能なコンテナの一覧、セキュリティ要件 PDF [9]の準拠状況、セキュリティスキャン結果のレポートなど、利用者が信頼性の高いコンテナを入手してそれらを検証するための機能をWeb UI（図2）として提供しています。

Iron Bankで提供されるコンテナイメージは、以下のとおり、マルウェア検知や脆弱性診断といった対応に加えて、コンテナイメージ、Dockerfile、コンテナ内OS等のコンプライアンス対応（適切な構成や設定等）など、コンテナイメージで考慮されうるセキュリティ要件を幅広くカバーしています。

マルウェア検知
脆弱性対応
コンテナイメージの推奨構成
Dockerfileの推奨構成
依存パッケージの構成情報
OSイメージの推奨構成
不要なパッケージの削除
シークレット管理
ライセンス情報
署名の付与

総じて、Iron Bankで提供されるコンテナイメージは、コンテナセキュリティ関連のガイドであるNIST SP 800-190 PDF [10] やContainer Hardening Process Guide PDF [11]などで言及されているコンテナイメージの要件を概ね満たしているといえます。特に、脆弱性診断をはじめとしたセキュリティテストが定期的に実施され、診断結果に対する見解まで文書化されて提供される点はDocker Hubよりも優れているといえます。具体的には、表2の検出カテゴリに対して、修正やリスク受容などの対処状況や見解が示されています。

表2. 検出された脆弱性のカテゴリ

ラベル	概要
False Positive	診断ツールがパッケージやバージョンなどを誤って識別
Disputed	NVDにおいて、他のCVE番号への統合や係争中等の理由により将来削除される、または削除される可能性がある
Won't Fix	アップストリーム開発元で修正の意思がない
Distro - Won't Fix	ディストリビューション開発元で修正の意思がない
No　Fix Available	利⽤可能なパッチが存在しない
Distro - Pending Resolution	最新版パッケージにおいて解決されていない
Mitigated	緩和策が存在している
Not Vulnerable	アプリケーション内では悪⽤できない
Unreleased	修正がリリースされていない
Pending Resolution	修正が対応中である
True Positive	検出直後のデフォルト状態

このような情報が提供されることで、本来利用者側で実施すべき脆弱性の検出や対処のコストが削減できます。

次に、コンテナイメージのコンプライアンス対応については、コンテナ技術固有の設定や従来環境（ベアメタル環境や仮想環境）も適用されるOSやミドルウェア等の設定も含まれます。特に、OSやミドルウェアのセキュリティ設定の参考となるものは、CIS（Center For Internet Security）が発行しているCIS Benchmarks new window [12]や米国国防総省（DoD）の国防情報システム（DISA）が発行しているSecurity Technical Implementation Guides（STIGs）[13]があります。ただし、これらのガイド類が対象としているのはあくまでベアメタル環境や仮想環境にインストールされた際の推奨構成であり、GUI構成や特定機能を含まないコンテナ内コンポーネントには適用されないケースが存在します。つまり、関連する診断ツールで検査した場合は多数の誤検知が想定されます。例えば、STIGs要件において通常のRHEL7 OSに適⽤される構成設定は 363項目ありますが、コンテナ内において93項目は対象外とされています。コンテナイメージの利用者側においてこのような判断を一から実施するのはコストがかかるため、脆弱性対応と同様に、診断結果や見解が文書化されている点は有益といえます。なお、CIS BenchmarksやSTIGsが提供されているOSがコンテナ内で利用できない場合は、アプリケーションの実行に必要な最小限のファイルのみを含む軽量なコンテナイメージから構築するアプローチも取られています。

Iron Bankで公開されるコンテナイメージでは、ソフトウェアサプライチェーンの観点も考慮されています。例として、コンテナイメージの構築に必要となる依存パッケージは事前にインターネット経由でダウンロードされ、安全であることが検証されたうえで、オフラインのビルド環境で取り込まれます。このアプローチによって、ビルド工程で予期せずに安全性が担保されてないモジュールが成果物に組み込まれることを防止しています。また、コンテナイメージの構成情報はSBOMとしても提供され、チェックサムや署名も付与されているため、改ざんや提供元の検証も可能となっています。

上述のとおり、Iron Bankでは、十分なセキュリティ要件を満たしたコンテナイメージが利用者側で検証できる形で提供されています。そのため、第3者が提供するベースイメージを採用したとしても、利用者はセキュリティ対応コストを抑えることができます。

まとめ

今回は著名なパブリックレジストリであっても手放しで信頼できないことや、より信頼性の高いコンテナイメージを提供するIron Bankを紹介しました。Iron Bankで提供されるコンテナイメージを利用することで、利用者側でのセキュリティ対応コストを抑えることが期待できます。また、Iron Bankのコンテナイメージを採用しない場合であっても、類似の機能を持つコンテナイメージのセキュリティ対応（脆弱性対応やコンプライアンス対応）の参考とする扱いも可能です。

コンテナのベースイメージは、開発やアプリケーションの動作に必要な機能が提供されていることも重要ですので、必ずしもセキュリティ要件のみで選択すべきものではありませんが、今回ご紹介した内容がコンテナ開発時の参考になれば幸いです。