コアとなるセキュリティ戦略としてのコンテインメント

読了時間：5分

出典：Charlotte Allen（Alamy Stock Photo経由）

論評

原子力安全設計において、隔離はすべてです。コンテインメント（封じ込め）が失敗すれば、システムも失敗します。チェルノブイリでは、性能目標を達成するために隔離プロトコルが無視されました。原子炉が過熱したとき、連鎖的な失敗を防ぐ効果的な障壁はありませんでした。この出来事は単なる技術的な故障ではなく、厳格な制限を守ることに失敗したシステム全体の問題でした。福島第一原発事故も同様に、最初の地震ではなく、コンテインメントの喪失によって被害が拡大しました。浸水したバックアップ発電機が冷却システムを停止させ、過熱によって炉心が損傷しました。

これらの災害は、最も重大な失敗は一つの部品の故障によって引き起こされるのではなく、部品間の障壁が不十分であることによって引き起こされることを思い出させてくれます。ソフトウェアにおいても、同じく容赦のない被害範囲に直面しています。現代の侵害条件に耐えうるシステムを望むなら、原子力のコンテインメントと同じ発想で構築する必要があります。安全を前提とするのではなく、隔離を徹底するのです。

なぜコンテナは「封じ込め」にならないのか

今日のマルチテナントインフラ、特にクラウドネイティブ環境では、コンテインメントはしばしば「模擬」されているだけで、実際には存在しません。ほとんどのアプリケーションはコンテナで実行されており、広く隔離されていると考えられています。しかし、コンテナは同じオペレーティングシステムのカーネルを共有しています。実際の隔離単位ではありません。いくつかの名前空間が設定されたプロセスに過ぎません。カーネルの脆弱性を突かれると、攻撃者はワークロード間を横断でき、テナント分離という前提が破られます。

この誤解は運用上の罠を生みます。チームはコンテナの隔離を信頼できないため、より多くのクラスタを作成し、約束されたセキュリティ境界を再現するためにインフラを複製します。その結果、コストの膨張、スケジューリングの非効率化、脆弱なアーキテクチャが生じます。Linuxカーネルは、何百もの機密ワークロード間の最終防衛線となるよう設計されていません。テナントごとのリソース使用量を正確に追跡できません。ファイルシステムのマウントを完全に制限することも、シンボリックリンクやカーネルモジュールを利用した攻撃連鎖を防ぐこともできません。その結果、1つのコンテナが侵害されると、その被害範囲はノード全体に及びます。

侵害を効果的に封じ込めるには、カーネルより下のレイヤーに存在する隔離のプリミティブが必要です。パラバーチャライゼーションされたハイパーバイザーのようなシステムは、ハードウェアによる分離でこれらの境界を強制できます。このモデルでは、ワークロードはカーネル空間を共有できません。仮想マシンの1つが侵害されても、攻撃者がハイパーバイザー自体を侵害しない限り、他の仮想マシンには移動できません。それははるかに高いハードルであり、形式手法や制限されたコード実行領域によって監視・最小化することができます。

未知の脆弱性という氷山

しかし、隔離だけでは十分ではありません。多くの防御者は既知の脆弱性だけに注目します。これらはCVEや名前・パッチのある脆弱性であり、氷山の目に見える部分です。しかし、より大きな脅威はその下に潜んでいます。それが未知の脆弱性です。これには、設定ミス、依存関係の連鎖、権限の肥大化、まだ発見されていないロジックの欠陥などが含まれます。未知の問題の難しさは、どんなスキャナーでも検出できないことです。手遅れになるまでアラートも発生しません。未知の脅威に対抗するには、侵害を前提に設計し、その拡大範囲を制限するシステムが必要です。

よくあるコンテナイメージの強化手法の一つは、イメージをスリム化することです。これは通常、不要なファイルやライブラリを削除して攻撃対象領域を減らすことを意味します。スリム化されたコンテナイメージは、最小限のベースイメージや未使用コンテンツを削除するツールで構築されることがあります。これは役立ちますが、問題の一部しか解決しません。これにより既知の脆弱性は減らせますが、実行時の境界が強固でない限り、未知の脆弱性への露出は減りません。

一部のツールはテスト時に利用されたコンテンツに基づいて削除を行います。しかし、テストで機能やロケールを見落とすと、その機能が削除され、本番環境で障害が発生する可能性があります。より良い方法は、ビルド時分析を使ってアプリケーションに合わせた最小限のイメージを構築することです。それでも十分ではありません。アプリケーションが共有カーネル上で動作している場合、単一の障害が境界を越えることがあります。イメージの衛生管理は侵入経路を制限しますが、拡大を防ぐのは強力な隔離だけです。

AIと隔離の重要性の高まり

この問題は、人工知能の時代において、かつてないほど重要になっています。AIワークロードは計算集約的であるだけでなく、リソースの使い方が予測不可能です。特にGPUは新たな脆弱性をもたらします。現在のAIインフラの多くは、依然としてコンテナレベルの隔離を前提とし、GPUのような高性能ハードウェアを共有環境に割り当てています。これは非常に大きなリスクです。GPUドライバの脆弱性により、攻撃者がカーネルにアクセスできる場合、データの持ち出し、学習データの改ざん、隣接ワークロードへの干渉が可能になります。

これらの脅威は仮定の話ではありません。GPUドライバのバグによるカーネルレベルのメモリ破壊は繰り返し発生しています。さらに、モデルの重みや推論リクエスト、微調整パラメータなどはすべて機密性の高い知的財産であり、侵害によって失われるのは単なるダウンタイムだけではありません。

強力な隔離こそが最も信頼できる戦略です。隔離によって、GPUを単一テナントに安全に割り当てることができます。AIワークロードは、信頼できないプロセスとメモリ空間を共有せずにフルパフォーマンスで実行できます。ワークロード自体が不透明で急速に変化していても、強制可能な信頼境界を作り出せます。

ボトムアップでレジリエンスを構築する

教訓はこうです。隔離は単なる古いセキュリティの考え方ではありません。新しい技術を安全に導入するための前提条件です。AI、エッジコンピューティング、機密データパイプラインなど、これらのシステムは、周囲すべてを巻き込まずに失敗できるときにのみ機能します。隔離境界によってリスクを分割できるのは、何が問題になるかを正確に知っているからではなく、いずれ何かが必ず問題になると知っているからです。

原子力工学では、コンテインメントドームは原子炉が永遠に完璧に動作するという前提で作られることはありません。失敗に耐えられるように作られています。私たちのソフトウェアシステムも同じように設計されなければなりません。脆弱性が現れるたびに対応し続けるのではなく、未知の脅威の存在を前提とし、それらが影響を及ぼせる範囲（被害範囲）を減らす必要があります。そのためには、境界を正しい場所に置くことから始めます。コードの周囲ではなく、ワークロードの周囲に。名前空間の周囲ではなく、実行領域の周囲に。これらの境界をハードウェアレベルで強制できれば、高性能であるだけでなく、レジリエントなデジタルシステムを構築できる可能性が生まれます。そしてAI時代において、このレジリエンスはもはや選択肢ではありません。