パッチ適用が追いつきませんか？最後の防衛線としてのゼロトラスト

新機能の追加やアプリケーションの進化のスピードは、アーキテクチャの複雑さを直接的に増大させます。この絶え間ないペースは、単に新機能への要望によって推進されているだけではありません。新たな脆弱性が絶えず発見されることで、ますます加速しています。それぞれの製品やソリューションには、有効/無効を切り替える無数の実装オプションやさまざまな機能があるため、1 つの重要な依存関係にパッチを適用することで、何段階にもわたる必要なアップデートや予期せぬアーキテクチャの変更が発生します。この複雑さを特定の環境に合わせて調整しようとすると、すべてのコンポーネントが業界のベストプラクティスに従ってデプロイされることを保証することが困難になります。検証済みパターンは、さまざまなユースケースに対してすぐに使える十分にテストされたデプロイメント・パターンを提供することでこのギャップを解消します。これにより、複雑なセキュリティ重視のアーキテクチャをゼロから構築する必要性を軽減できます。

脆弱性管理に関する望ましくない事実

2025 年には、4 万件を超える新しい CVE が公開されました。その数は毎日 100 件を超えています。現在、AI を活用したエクスプロイト生成により、脆弱性の公開から実際の悪用までの時間が大幅に短縮されています。「Chasing the holy grail (究極の目標の追求)」のブログ記事では、ゼロ CVE という完璧なスコアを追求することが、より深い多層防御戦略の妨げとなる場合に、逆効果になる場合があることを示しています。午前 9 時の時点で「クリーン」なコンポーネントであっても、午後 5 時までには新たに脆弱性が公開されている可能性があります。既知の CVE がゼロになった場合でも、未知の脆弱性は常に残ります。

パッチ適用の計算 (CVE が少ないほどリスクが低いという、セキュリティを単なる数字のゲームと捉える誤解) は、何百ものコンテナ化されたワークロードを実行しているエンタープライズ環境には単純に当てはまりません。単一のオペレーティングシステム上で実行される従来のモノリシックなアーキテクチャとは異なり、分散コンテナ環境ではアーキテクチャの複雑さが大幅に増大します。無数のマイクロサービスやネットワークのタッチポイントによって構成オプションが大幅に増えますが、そこで問題が発生すると、意図せずセキュリティ上の脆弱性が生じる可能性が高まります。すべてを即座に修正しようとするのは、現代のリスクベースのセキュリティ戦略と矛盾する、際限のない困難な作業です。また、どれほど積極的にアップデートを適用しようとしても、必ず遅れが生じるという基本的な事実が見落とされています。

では、脆弱性の公開からパッチのデプロイまでのギャップ期間にはどうすればよいのでしょうか。その答えは、何年も前から存在していますが、現在ではこれまで以上に重要となっている、次のようなセキュリティ原則にあります。ゼロトラスト・アーキテクチャ

Red Hat OpenShift クラスタにおけるゼロトラストが意味すること

ゼロトラストはインストールする製品ではありません。これは、すでにセキュリティ侵害が発生していることを前提としたアーキテクチャの考え方であり、あらゆるやり取りについて明示的な検証と認可が必須であると定めるものです。NIST SP 800-207 によると、ゼロトラストとは、物理的またはネットワーク的な場所のみに基づいてリソース (アセット、アプリケーション、またはユーザーアカウント) に付与される暗黙の信頼を排除することを意味します。認証と認可は、エンタープライズリソースへのセッションが確立される前に実行される個別の機能です。

Kubernetes と Red Hat OpenShift でゼロトラストを実装するには、ワークロード ID、シークレット管理、ランタイムアクセス制御に及ぶ多層アプローチが必要です。とくにネットワーク領域において、この理念の最も重要な影響の 1 つは、すべての Pod が自由に通信できるデフォルトのフラットなネットワーク体制から移行することです。デフォルトでは、Kubernetes は内部ネットワークの制限を適用しません。これは、建物にフロントゲート (クラスタ Ingress コントローラー、API ゲートウェイ、境界ファイアウォールなど) があるという理由だけで、建物のすべての内部ドアに鍵をかけないままにすることと同じです。しかし、この境界防御のみに頼ることは、現代のクラウドネイティブ環境においては根本的に不十分です。

ゼロトラストモデルに基づき、Red Hat は侵害がすでに発生しており、境界を突破した外部の攻撃者、侵害されたサプライチェーン・コンポーネント、または内部から直接操作する悪意のある内部脅威などの攻撃者がすでに環境内に存在していると仮定します。Kubernetes のネットワークリソース制限を実装することで、ネットワークの使用や接続された他のリソースへのアクセスに対して明示的な認証と認可を必要とする、「デフォルト拒否」のネットワーク接続を作成します (図 1)。

理論から実践へ：階層化されたゼロトラスト検証パターン (ZTVP)

これらのベストプラクティスを現実のものにするために、Red Hat は 階層化されたゼロトラスト検証パターン (ZTVP) を活用します。検証済みパターンは IaC (Infrastructure as Code) のベストプラクティスと GitOps による自動化を具現化したもので、セキュリティとスケーラビリティを考慮して設計された複雑な OpenShift デプロイメントの設定時間を大幅に短縮します。過去 3 カ月間で ZTVP プロジェクトは大きく前進し、Tested Tier の認定を取得しました。

このパターンは、複数のコンポーネントを統合し、GitOps でデプロイされる一貫したゼロトラスト・アーキテクチャを構築します。

• ゼロトラスト・ワークロード ID マネージャー：SPIFFE/SPIRE プロジェクトに基づき、短期間のみ有効な暗号化された ID をワークロードに提供します。
• HashiCorp Vault：JWT 認証のために ZTWIM と統合され、機密アセットとクラスタのシークレットをセキュリティ最優先の方法で保存します。
• Keycloak の Red Hat ビルド：ユーザー認証とフェデレーテッド ID を管理します。
• Red Hat Advanced Cluster Security for Kubernetes：インテリジェントなセキュリティの「頭脳」として機能し、統合されたマルチクラスタ監視、プロアクティブなアクセス制御、リアルタイムの動作異常検出、そしてこの例ではとく重要なネットワーク・ポリシー・アナライザーを提供します。

ネットワークポリシー：最後の防衛線

ネットワークポリシーはゼロトラストの基盤としてよく議論されますが、それ自体は原則ではありません。ネットワークポリシーは、ゼロトラストモデルの望ましい結果を実現するために使用される、プロアクティブなアーキテクチャ上のメカニズムです。Red Hat は ゼロトラストの 4 つの中核となる原則について概説しており、適切に設計されたネットワークポリシーはそのすべてを積極的にサポートしています。

• マイクロセグメンテーション：個々の Pod レベルでトラフィックを管理することにより、ネットワークポリシーは本質的にクラスタを粒度の細かいセキュリティ強化されたセグメントに分割します。
• 最小特権アクセス：デフォルト拒否の体制では、ワークロードには、その機能に絶対に必要なネットワーク権限のみが与えられ、それ以上の権限は一切与えられません。
• 境界の解除：セキュリティ制御はクラスタの「フロントゲート」だけでなく、ワークロード自体の周囲に直接適用されます。
• 侵害を想定する：水平方向の攻撃経路をプロアクティブに排除することで、厳格な Ingress および Egress ルールが設定され、侵害が発生した瞬間に影響範囲を封じ込めることができます。

さらに、Kubernetes ネットワークポリシーの非常に重要な側面は、保護対象のアプリケーション Pod とは別のコントロールプレーンに存在することです。つまり、攻撃者がコンテナの侵害に成功し、そのアプリケーション内で昇格された権限を取得したとしても、自らを制限しているネットワーク境界を簡単に再定義したり回避したりすることはできません。内部環境の全体的なセキュリティポスチャを強化し、これらの原則を実際に適用するには、Pod レベルで Ingress と Egress の両方のトラフィックを管理するきめ細かなネットワークポリシーを定義する必要があります。

• Ingress ポリシー：これらは Pod への受信トラフィックを制御し、サービスが明示的に認可されたソースからの接続のみを受け入れるというルールを適用します。クラスタ内の隣接する Pod のセキュリティが侵害された場合でも、強力な Ingress ポリシーによって攻撃者が機密ワークロードに水平方向にアクセスするのを防ぎます。
• Egress ポリシー：これらは Pod からの送信トラフィックを制御します。その目的は、Pod が到達できる外部または内部のリソースを厳密に制限することです。Pod のセキュリティが侵害された場合、Egress ポリシーは、攻撃者がデータを盗み出したり、広範なネットワーク偵察を行ったり、外部のコマンド & コントロールサーバーから悪意のあるペイロードをダウンロードしたりする能力を無効化します。

デフォルト拒否の基盤

具体的な Ingress および Egress ルールの定義は不可欠ですが、それだけに頼ると危険なギャップが生じ、ヒューマンエラーや欺瞞的な攻撃を許してしまう可能性があります。デフォルトでは、Kubernetes は allow-all モデルで動作するため、明示的に制限されていないすべてのトラフィックが許可されます。開発者がポリシーの適用を忘れるだけで、その Pod は無防備な状態になります。しかし、リスクは単なるミスだけではありません。サプライチェーン攻撃では、開発者が知らないうちに侵害されたサードパーティのコンポーネントをデプロイさせられ、隠された悪意のあるペイロードやその影響にまったく気づかない可能性があります。

デフォルト拒否ポリシーは、このパラダイムを拒否リストから許可リストへと転換します。ゼロトラストの中核原則では、すべての対話が明示的に認可される必要があるため、論理的には、暗黙的なアクセスは一切認められません。最初からすべてのトラフィックを厳格にブロックする「デフォルト拒否」の体制をとることで、不注意による見落とし (あるいは巧妙に偽装された不正なコンテナがホームサーバーへの通信を試みた場合) があっても、その接続は安全にブロックされる環境が構築されます。設計段階から明示的にアクセス権を付与することが強制されるため、気づかないうちに発生する壊滅的な侵害を、目に見える形で簡単に修正できるデプロイメントエラーに変えることができます。

このアプローチは、次のようなシンプルで強力なルールから始まります。デフォルトですべてのトラフィックを拒否するすべての namespace は、明示的な許可ポリシーが存在しない限り、すべての Pod のすべての Ingress と Egress をブロックするデフォルト拒否の NetworkPolicy を受け取ります。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-in-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

NetworkPolicy が namespace 内の Pod をターゲットにするとすぐに、その Pod は無制限のアクセスを維持できなくなります。デフォルトでアクセスをブロックするポリシーを定義することで、「デフォルト拒否」のゼロトラスト体制に合致させることができます。

パッチを適用できない場合にこれが重要である理由

悪名高い Log4j の危機や、React2Shell の脆弱性 (CVE-2025-55182) のような最近のフレームワークのセキュリティインシデントを思わせるある企業でのシナリオを考えてみましょう。

1. アプリケーションで使用されている、広く普及しているライブラリに、重大なリモートコード実行 (RCE) の脆弱性が突如として公表されました。
2. この脆弱性により、攻撃者が影響を受けるサービスに対して特別に細工されたリクエストを送信するだけで、サーバーを完全に乗っ取ることが可能になります。
3. このライブラリは依存関係に深く組み込まれているため、検証済みのパッチであっても、テストに合格し本番環境にデプロイされるまでには数日かかります。

ゼロトラスト・ネットワーク・ポリシーを導入している組織への影響は最小限になります。

• Pod のセキュリティを侵害した攻撃者は、任意の namespace を介して脆弱なサービスに簡単に到達できます (水平方向の分離はありません)。
  • ZTVP ネットワークポリシーを使用する場合：攻撃者は、別の namespace からサービスに到達できません (namespace の分離)。
• 攻撃者は、重要なポートや管理ポートなど、サービス上の任意の公開ポートに接続できます (ポートレベルのフィルタリングはありません)。
  • ZTVP ネットワークポリシーを使用する場合：攻撃者は、明示的に許可されていないポートに接続できません (ポートレベルのフィルタリング)。
• 攻撃者は、自由にアウトバウンド接続を行い、データを盗み出したり、コマンド & コントロール (C2) チャネルを確立したりすることができます (Egress 制限なし)。
  • ZTVP ネットワークポリシーを使用する場合：攻撃者は外部のエンドポイントにデータを盗み出すことができません (Egress 制限)。

デモ：攻撃経路の排除

Red Hat は、適切に実装されたネットワークポリシーによってどのように攻撃経路が排除されるかを正確に確認できるデモ動画を作成しました。最初は、デフォルト拒否の体制がない環境を確認します。この環境では、サプライチェーンの脆弱性を利用した攻撃者が簡単に広範な偵察を行い、ネットワークを自由にスキャンして、パッチが適用されていない他のコンポーネントを悪用できます。次に、厳格なネットワークポリシーが適用されると、状況が完全に変わることを確認します。

攻撃者が Pod の侵害に成功したとしても、ネットワークを調査したり、脆弱性をスキャンしたり、水平方向に移動したりする能力は完全に無効化されます。これらのポリシーにより、脅威は侵害されたコンテナ内に封じ込められ、事実上脅威の拡散が阻止されるため、是正措置を講じるために必要な貴重な時間を確保することができます。包括的なセキュリティ戦略において、ネットワークポリシーは唯一のフェイルセーフではないかもしれませんが、厳格なネットワーク境界を確立することは、最後の防衛線を構築するための最良の出発点と言えます。

このデモでは、ネットワークポリシーによって攻撃が侵害されたコンテナ内に制限される様子が示されています。これにより、脅威を効果的に封じ込め、是正措置を実行するために必要な貴重な時間を確保できます。

全体像：深いレベルまで保護

ネットワークポリシーは、包括的な戦略の 1 つの層にすぎません。階層化されたゼロトラスト検証パターンでは、これらのポリシーを SPIFFE/SPIRE ワークロード ID (ゼロトラスト・ワークロード ID マネージャーを使用)、Vault で管理されるシークレット、ID プロバイダー (IdP) を使用した一元化された認証 (デフォルトの Keycloak の Red Hat ビルドなど)、および Red Hat Advanced Cluster Security for Kubernetes によるランタイム監視と組み合わせます。ネットワークポリシーは、ID、シークレット、アプリケーションのセキュリティに問題が生じた場合でも、ネットワーク層が封じ込めを確実に行うことで、全体的な防御を完成させます。

しかし、ネットワークポリシーが実際に機能しているか、またはセキュリティが侵害されたコンテナが内部の境界を繰り返しプローブしているかどうかを、どのように判断すればよいでしょうか。ゼロデイエクスプロイトによって接続が拒否された場合、何が起こるでしょうか。

Red Hat は、階層化されたゼロトラスト検証パターンがどのようにゼロトラストのセキュリティ対策を実装しているかを探るこの一連のブログを通じて、これらの重要な質問に答えます。今後の内容は次のとおりです。

• Red Hat Advanced Cluster Security for Kubernetes によるアクティブな防御：詳細なランタイム監視、自動化されたネットワーク・ポリシー・スキャン、リアルタイムのアラートを実装し、セキュリティの中枢として機能させます。
• ID とシークレット：ゼロトラスト・ワークロード ID マネージャーと Vault の統合により、ワークロード ID をより安全に管理します。
• サプライチェーン：コンテンツの署名を適用し、パイプラインタスクを検証することにより、ソフトウェアサプライチェーンをエンドツーエンドで保護し、信頼できるコードのみがクラスタに到達するようにします。

実際の動作を見る次の記事を待たずに、今すぐ使い始めることができます。階層化されたゼロトラスト検証パターンでアーキテクチャを確認し、ネットワークポリシーのデモを実際にお試しください。

参考資料

• NIST SP 800-207：ゼロトラスト・アーキテクチャ
• NIST SP 800-207A：クラウドネイティブ・アプリケーションのゼロトラスト
• CISA：ゼロトラスト・マイクロセグメンテーションに関するガイダンス
• 階層化されたゼロトラスト検証パターン
• 検証済みパターン
• Chasing the Holy Grail:Why Red Hat's Hummingbird Project aims for near-zero CVEs
• CVE メトリクス