あらゆるレイヤーにおける信頼：シーリングされたイメージがブートからランタイムまで OS の整合性を拡張する仕組み

病院で Linux が実行されている医療機器について考えてみましょう。この医療機器は、患者データの処理、投与量を調整し、臨床システムに報告を行います。または、24 時間体制で取引を処理する街角の ATM について考えてみてください。さらに、製造ネットワークのエッジにあるゲートウェイ機器が、工場現場からのセンサーデータを中継しているケースもあります。これらの各デバイスのオペレーティングシステム (OS) は、インストール時に検証されています。しかし、すべてのバイナリーやライブラリは、現在もビルド時とまったく同じ状態でしょうか。手術室や工場現場にあるデバイスに対してその保証を求めるのであれば、ビジネスを支えるサーバーに対しても同じことを期待すべきではないでしょうか？　

ブートチェーンにおけるギャップ

通常、デフォルトの汎用オペレーティングシステムのインストールは「ロック解除」された状態で提供されるため、ユーザーはコンピュータ上で root 権限を取得し、永続的な変更を加えることができます。そのため、汎用の Red Hat Enterprise Linux (RHEL) や Debian のインストールはセキュアブートをサポートしていますが、通常はカーネルのみが署名されています。ファームウェアからの暗号的な信頼チェーンは、ルートファイルシステムやアプリケーションには及んでいません。しかし、「アプライアンス」の作成を希望する組織の場合、カスタム署名を使用して、セキュアブートからオペレーティングシステムの整合性までをチェーン化することで、セキュリティを強化することが可能です。

コンテナワークフローから OS の整合性へ

ほとんどの組織はすでに、CI/CD パイプラインを通じてコンテナイメージのビルド、署名、提供を行っています。コンテナをプルするたびに、暗号化ダイジェストが検証されます。新しいコンテナが起動するたびに、ランタイムはイメージが署名された内容と一致することを確認します。多くの組織はすでに、それぞれのアプリケーションに対してこのモデルを信頼しています。

RHEL のイメージモードは、これと同じコンテナワークフローをオペレーティングシステム自体に導入します。手動やスクリプトで OS をインストールして設定する代わりに、Containerfile (または他の互換性のある OCI ビルドシステム) で OS を定義し、コンテナイメージとしてビルドして、bootc でデプロイします。これにより、OS はバージョン管理され、再現可能なアーティファクトとなり、アプリケーションと同じパイプラインを通過するようになります。更新はアトミックに行われます。ロールバック機能も組み込まれています。デプロイされたすべてのシステムで、ビルドしたイメージが実行されます。また、そのイメージを生成したビルドシステムまで遡って追跡することができます。

イメージモードによって可能になる「シーリングされたイメージ」は、これをさらに一歩先に進めます。ビルドして署名した OS イメージは、ファームウェアからランタイムに至るまで暗号化技術で検証されます。これは新しいプロセスを採用するということではなく、すでに信頼しているプロセスを、アプリケーションから OS レイヤーへと拡張するものです。

仕組み

セキュアブートと署名済みの統合カーネルイメージは、ブートチェーンを検証しています。ブートチェーンには、ブートローダー、カーネル、initramfs が含まれます。シーリングされたイメージでは、検証の範囲が不変の OS イメージそのものへと拡大され、ファイル単位の精度で検証が可能になります。composefs と fs-verity を使用することで、OS コンテナイメージの暗号化ダイジェストが、ビルド時に署名済みの UKI に直接組み込まれます。ランタイム時に、お客様やチームがそのイメージに追加したすべてのファイルが、そのダイジェストに対して個別に検証されます。システムは、一致しない OS ファイルのロードを拒否します。イメージのビルド後に何かが変更、破損、または置き換えられた場合、カーネルは I/O エラーを返します。さらに、そのファイルは提供されず、ログを記録して提供されることも、フラグを立てて提供されることもありません。そのファイルは単に読み取り不能になります。改ざんされたコンテンツは事実上存在しないことになるため、カーネルはどのプロセスにもそのコンテンツを渡しません。

インフラストラクチャにおけるメリット

署名チェーンは、お客様の管理下に置かれます。お客様自身がキーを生成し、イメージに署名し、システムに何を信頼させるかを決定します。管理の連鎖においてベンダーを介在させる必要はありません。

政府、金融、医療機関などの高度なセキュリティを必要とする組織は、長年にわたりこのレベルの OS 整合性を求めてきました。シーリングされたイメージはこれらを可能にし、それを必要とするあらゆる組織が利用できます。オペレーティングシステムが構築したとおりの状態であることを把握できるメリットは、規制対象の業界だけでなく、すべての組織が享受できます。

シーリングされたイメージが何を保護するのかについて、正確に理解しておくことは重要です。シーリングは、イミュータブルな OS イメージ内のファイルを保護するためのものです。ベースとなるオペレーティングシステム、およびその上にレイヤー化されたすべてのソフトウェアをはじめ、監視エージェント、セキュリティツール、アプリケーションバイナリー、およびチームがベースイメージに追加した特定のパッケージなど、これらすべてがシーリングされます。これは、/etc 内の書き込み可能な設定や /var 内のランタイム状態は対象としません。この区別は意図的なものです。シーリングは、お客様が構築した OS を保護するためのものです。それ以外の部分は、構成管理ツールやランタイムのセキュリティツールによって保護されます。

この記事の冒頭で、医療機器や ATM について触れましたが、これはそれらの例にとどまりません。データセンター、エッジフリート、または製造現場を想定してみてください。1 つの Containerfile が OS を定義します。1 つのパイプラインでイメージのビルド、署名、シーリングが行われます。同じシーリング済みのイメージを、ベアメタル、VM、クラウドインスタンスにデプロイできます。どこにデプロイしても、同じ整合性が維持されます。これは、特定のユースケースに限定したニッチな機能ではありません。これこそ、OS の整合性のあるべき姿です。

今すぐ始める

シーリング済みのイメージは、RHEL 10.2 のテクノロジープレビューとして利用可能です。これは、systemd プロジェクトの主要コンポーネント、セキュアブートや composefs に関連する既存のツールなど、アップストリームの Linux テクノロジーをベースに構築されています。これによって、dm-verity が提供するような整合性を、ファイルシステムベースのアプローチ特有の柔軟性を備えた、効率的かつ柔軟な方法で実現できます。これは OS 管理の今後のあり方と言えます。現在、このテクノロジープレビューは公開されており、ツールも利用可能です。Red Hat は、今後数週間にわたって Red Hat Developer Blog で具体的な手順についてのシリーズ記事を公開し、この方法でのシステムの構築と検証が実環境でどのように行われるかについて解説します。