はじめに
第1回では、UBI Microを使う理由を次の2本柱で整理しました。
- アプリが使っていないOSパッケージを減らし、CVE対応対象を小さくする
- 侵入後に攻撃者が使えるOS上の道具を減らす
この2つを考える前提として、重要なのが OS部分とアプリ部分を分けて考える ことです。
OSにWebSphere/Libertyを直接インストールして使う構成では、OS、Java、Liberty、アプリケーション、運用ツールが1つの環境に混ざりやすくなります。コンテナでは、これらを層として分けて考えやすくなります。
この分離ができると、CVEが出たときに「何を直すのか」「どこまで確認するのか」を整理しやすくなります。
VM単位からアプリ単位へ
OS部分とアプリ部分を分ける話は、VM型とコンテナ型の違いにも関係します。
VM型では、アプリケーションごと、またはシステムごとにOSを含む実行環境を持つことが多くなります。
そのため、OSパッケージ、Java、Liberty、アプリケーション、運用ツールがVM単位でまとまりやすくなります。
コンテナ型では、ノードOSの上でアプリケーションコンテナを動かします。
アプリケーションごとにOS全体を抱えるのではなく、コンテナイメージとして必要なランタイムとアプリケーションをまとめます。
このとき、ベースイメージ層とアプリケーション層を分けて考えられることが重要になります。
つまり、コンテナ化のメリットは、単に起動が速いことや配置しやすいことだけではありません。
OS由来の変更とアプリ由来の変更を分けて扱いやすくなる ことにもあります。
OSにインストールして使う構成で起きやすいこと
OSにWebSphere/Libertyをインストールして使う場合、1台のサーバーにいろいろなものが積み重なります。
OS
OSパッケージ
Java
WebSphere / Liberty
アプリケーション
アプリ依存ライブラリ
運用ツール
調査用コマンド
一時的に追加したパッケージ
この構成自体が悪いわけではありません。ただし、脆弱性スキャンやCVE対応の観点では、切り分けが難しくなることがあります。
たとえば、スキャン結果にCVEが出たときに、次を確認する必要があります。
- OSパッケージ由来なのか
- Java由来なのか
- Liberty由来なのか
- アプリケーションの依存ライブラリ由来なのか
- 後から入れた運用ツール由来なのか
- アプリケーションが実際に使っているのか
- 使っていないなら削除できるのか
この切り分けが曖昧だと、修正対象も確認範囲も広がります。
コンテナでは層で考えやすい
コンテナでは、構成を次のように層で整理しやすくなります。
| 層 | 主な内容 | CVE対応の考え方 |
|---|---|---|
| OS/ベースイメージ層 | UBI、OSパッケージ | ベースイメージ更新、再スキャン、起動確認 |
| ランタイム層 | Java、Liberty | JDK/Liberty更新、feature互換確認 |
| アプリケーション層 | WAR/EAR、アプリ依存ライブラリ、アプリ設定 | 依存更新、アプリ機能テスト、回帰確認 |
| 観測・運用層 | Health Check、ログ、OpenTelemetry設定 | 設定確認、観測確認 |
UBI Microは、このうち OS/ベースイメージ層を小さくするための選択肢 です。
OS部分が小さくなると、OSパッケージ由来のCVE対象を減らしやすくなります。
CVEの出どころが分かると対応しやすい
CVEが検出されたとき、まず知りたいのは「どこにある問題なのか」です。
| CVEの出どころ | 主な対応 |
|---|---|
| OSパッケージ | ベースイメージ更新、不要なら削除 |
| Java | JDK/JRE更新、ベースイメージ更新 |
| Liberty | Libertyイメージ更新、構成確認 |
| アプリ依存ライブラリ |
pom.xml / build.gradle 等の更新 |
| アプリコード | コード修正 |
| 運用ツール | 使っていなければ削除、必要なら更新 |
OS部分とアプリ部分を分けておくと、この整理がしやすくなります。
テスト範囲も整理しやすい
脆弱性対応で大変なのは、修正そのものだけではありません。更新後に、どこまで確認すべきかを決めることも大変です。
| 変更内容 | 主な確認 |
|---|---|
| ベースイメージだけ更新 | 起動確認、Health Check、主要API、ログ、Telemetry |
| Libertyバージョン更新 | 起動確認、feature互換、主要機能、回帰確認 |
| Java更新 | 起動確認、主要処理、互換性影響 |
| アプリ依存ライブラリ更新 | アプリ機能テスト、回帰確認 |
| アプリコード修正 | 該当機能テスト、回帰確認 |
| 設定変更 | 起動確認、設定反映、接続確認 |
もちろん、重要なシステムでは十分な確認が必要です。ただし、OS部分だけを更新した場合と、アプリケーションコードを変更した場合では、確認すべき内容は同じではありません。
使っていないOSパッケージは、大荷物になる
アプリケーションが使っていないOSパッケージでも、イメージに含まれていれば脆弱性スキャンの対象になります。
たとえば、アプリが curl を使っていなくても、イメージに curl が入っていれば、curl やその依存ライブラリのCVEが検出される可能性があります。
その場合、使っているのか、削除できるのか、更新が必要なのか、残す場合どう扱うのかを確認する必要があります。
つまり、実行時には使っていないものが、CVE対応上の大荷物になることがあります。
UBI Microは、この大荷物を最初から減らすための選択肢です。
まとめ
OS部分とアプリ部分を分けて考えると、CVE対応と確認範囲を整理しやすくなります。
UBI Microは、そのうちOS部分を小さく保つための選択肢です。
次回は、実際にどのようなOS依存が残りやすいのかを見ていきます。