リスクがますます深刻化する中、コンテナ クラウド プラットフォームはどのようにしてセキュリティ分離を実現できるのでしょうか?

1. クラウドネイティブの技術的背景

現在、デジタルトランスフォーメーションはあらゆる業界に徐々に浸透しつつあります。弾力的なコンピューティングパワーは、あらゆる分野の「水、電気、石炭」となり、クラウドコンピューティングはデジタル世界の礎となり、産業変革を下から推進しています。クラウド コンピューティングが成熟段階に入るにつれ、「クラウドで生まれ、クラウドで成長する」という中核コンセプトを持つクラウド ネイティブ テクノロジーが、今後 10 年間のクラウド コンピューティングの重要な開発方向として注目されています。デジタル化の波の中で、クラウドへの移行は流行ではなく、厳密な必要性です。 「クラウドへの移行」から「すべての人のためのクラウドへの移行」、「クラウド化」から「クラウド ネイティブ」へ、これが企業がデジタル変革を実現する唯一の方法です。

従来の IT アーキテクチャと比較して、クラウド ネイティブには比類のない利点があり、コストの削減、効率性の向上、迅速な試行錯誤、イノベーションの促進など、企業にビジネス価値をもたらします。

クラウド ネイティブの技術的概念は、2009 年に Netflix やその他のベンダーがパブリック クラウド上で開発および展開の実践を開始したことから始まりました。2015 年に Cloud Native Computing Foundation (CNCF) が設立されたことで、クラウド ネイティブは技術的概念からオープン ソース実装へと変化しました。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。

クラウド ネイティブを使用すると、複雑で絶えず変化するエンタープライズ ビジネスを俊敏かつ柔軟に、応答性高く、迅速に反復できるようになり、デジタル変革と運用の継続的な革新が可能になります。現在業界で認識されているクラウド ネイティブを構成する 4 つのコア技術要素は、マイクロサービス、DevOps、継続的デリバリー、コンテナ化です。

2. クラウドネイティブ環境のネットワーク分離要件

ネイティブ テクノロジーは、アプリケーションのアップグレードの遅さ、アーキテクチャの肥大化、迅速な反復処理の不可能など、従来のクラウド プラクティスの「問題点」を効果的に解決し、ビジネス イノベーションの推進力となります。しかし、クラウドネイティブ テクノロジーはメリットを生み出す一方で、ますます深刻化するセキュリティ リスクにも直面しています。

たとえば、2018 年には、Tesla AWS にデプロイされた K8S ダッシュボードがパブリック ネットワークに公開されました。認証と承認の制御はなく、ネットワーク アクセスの制御もありませんでした。ハッカーはダッシュボードから直接 S3 認証情報を取得してテレメトリ データを取得し、悪意を持って POD をプルし、マイニング活動を実行しました。

「分離」テクノロジーは、最も古く、最も基本的で、最も中核的なセキュリティ テクノロジーの 1 つです。ガートナーが提案するコンテナ セキュリティ制御階層化理論では、コンテナ セキュリティ機能を、優先度の高い順に、基礎制御、基本制御、リスクベース制御に分類しています。その中でも、ネットワーク分離（L3 ネットワークセグメンテーション）は、必要な基本制御機能として分類されます。

CNCF が 2021 年に公開したクラウド ネイティブ セキュリティ ホワイト ペーパーでは、マイクロサービスとしてデプロイされたコンテナ化されたアプリケーションの境界はマイクロサービス自体であると指摘されています。そのため、許可されたマイクロサービス間の通信のみを許可するポリシーを設定する必要があります。

マイクロサービス アーキテクチャにゼロ トラストを導入すると、マイクロサービスが侵害されたときに横方向の移動を防ぐことができ、影響の範囲を縮小できます。オペレーターは、コンテナ展開内の東西ネットワーク通信が承認されたネットワークのみに制限されるように、ネットワーク ポリシーなどの機能を使用していることを確認する必要があります。

3. 従来のファイアウォールはクラウドネイティブでは限界がある

従来のデータ センターでは、提供するサービスの属性とセキュリティ レベルに基づいて、複数のセキュリティ ドメインに分割し、カスタマイズされたセキュリティ管理を実行することがよくあります。ファイアウォール システムは通常、アクセス制御を実装するためにセキュリティ ドメイン間に導入されます。クラウド プラットフォーム構築の初期段階では、このタイプのアーキテクチャが多数のユーザーによって採用され続け、ファイアウォールを使用してドメイン間アクセス制御ポリシーを実装していました。より高い管理レベルを持つ一部のユーザーは、アクセス元と宛先の IP アドレスに基づいてきめ細かいポリシー ルールを設定します。

しかし、クラウド プラットフォームが進化し、クラウド ネイティブ アーキテクチャに移行するにつれて、ファイアウォール ベースのドメイン間制御はクラウド ネイティブ環境と互換性がなくなり、コンテナー プラットフォームの分離要件を真に満たすことができなくなります。

ファイアウォールの展開場所と制御オブジェクトにより、ドメイン間のトラフィックのみを制御でき、よりきめ細かいビジネス レベルおよびワークロード レベルの制御は実行できないことが決定されます。さらに、ポリシーの規模がファイアウォールのパフォーマンスに与える影響を考慮すると、セキュリティ ポリシーの制御オブジェクトは、ネットワーク セグメント レベルでのみ実現できる場合が多くあります。したがって、正確に言えば、このようなソリューションは、データセンター インフラストラクチャの整合性を維持するための「マクロ セグメンテーション」を提供することはできますが、クラウド ネイティブ環境で本当に必要な「マイクロ セグメンテーション」を実現することはできません。

さらに、安定した IP アドレスは、ファイアウォール アクセス制御の継続的な有効性を維持するための「アンカー ポイント」となります。しかし、クラウドネイティブ環境では、コンテナ IP の頻繁かつ不規則な変更により、従来のアーキテクチャにおけるこの決定要因が完全に揺らぎます。コンテナが新しいライフサイクルを開始すると、新しい IP は元の静的ポリシーの有効な制御から直接逃れることになります。一方で、クラウドネイティブ環境ではコンテナの消滅や作成が頻繁に発生するため、その変化をリアルタイムで把握できたとしても、手動で元のポリシーを削除して新しいポリシーを確立することは不可能です。無効なポリシーが長期にわたって蓄積されると、ファイアウォール システム ポリシーの冗長性とパフォーマンスの低下という副作用が必然的に生じます。

クラウドネイティブ環境では、マイクロサービス アーキテクチャによってサービス間の相互アクセスと水平接続が飛躍的に増加し、すでに複雑な東西トラフィック制御に新たな困難がもたらされます。 DevOps のサポートにより、アプリケーションは俊敏かつ迅速かつ継続的に配信および展開され、セキュリティ制御対策では適切なエントリ ポイントを見つけて、常に変化するペースに対応する必要があります。

コンテナは新しい最小の制御ユニットとなり、そのライフサイクル パターンを見つけることはさらに困難になっています。新しいビジネスが立ち上げられたり、アプリケーションが更新されたり、容量が拡張または縮小されたりするたびに、コンテナは破棄され、再構築されます。このプロセスでは、インフラストラクチャを識別するために使用される従来の IP とホスト名が変更され、従来のセキュリティ ポリシー フレームワークが簡単にバイパスされ、回避されるようになります。

この観点から、ファイアウォールを使用してクラスター内トラフィックのマイクロ分離を実現するという期待を放棄したとしても、クラウドネイティブ環境でクラスター間トラフィックを効果的に分離して制御することは困難であり、クラウドネイティブアーキテクチャの下での本来の展開位置さえ失っています。実際、コンテナを大規模に導入し始めたユーザーは、ファイアウォール システムがほぼ完全に機能しないという問題を初めて発見することが多く、より緊急の分離と制御のニーズが生じます。

4. 既存のコンテナクラウドプラットフォーム分離ソリューションの分析

1. ネットワークポリシーに基づくコンテナの分離

ファイアウォールは「適応性の欠如」によりクラウドネイティブ環境では完全に機能しませんでしたが、これはクラウドネイティブ環境における「セキュリティネイティブ性」の重要性を改めて鮮明に示しています。実際、コンテナオーケストレーションプラットフォームのデファクトスタンダードとなっているKubernetes（以下、「K8S」）は、ネットワークポリシー機能を統合することでコンテナ間のネットワーク分離機能を提供しています。

K8S では、ネットワーク ポリシーによって Pod 間のアクセス制御仕様のセットが定義されます。ラベルを通じてネームスペースとポッドを指定し、ノードホストオペレーティングシステムの IPTABLES を使用してネームスペースとポッドレベルのネットワークアクセス制御を実装します。

プラグイン ファイアウォールと比較して、ネットワーク ポリシーはネイティブのセキュリティ機能を実装します。しかし、多くの実践から、その適用はほとんどのユーザーにとって依然として大きな制約を受けており、次のような顕著な問題があることがわかっています。

1) 環境適応性の限界

ネットワーク ポリシーはポリシー ルールの仕様のみを定義しますが、アクセス制御機能の具体的な実装は K8S プラットフォームのネットワーク プラグインに依存します。実際、すべての一般的な K8S ネットワーク プラグインがネットワーク ポリシー機能をサポートしているわけではありません。たとえば、かなりの数のユーザーが使用している Flannel プラグインは、この機能をサポートできません。ほとんどのユーザーにとって、ネットワーク ポリシー機能を実装するために元のネットワーク プラグインを置き換えて移行するコストは間違いなく高くなります。

さらに、ネットワーク ポリシー戦略のセットは、独立した K8S クラスターにのみ適用できます。一般的に複数の K8S クラスターを保有するユーザーの場合、ネットワーク ポリシーを使用してグローバル管理を実現したい場合は、より複雑なカスタム開発を行う必要があります。実装の難しさと管理コストは、ほとんどのユーザーにとって手の届かないものです。

2) 大規模な管理は難しい

ネットワーク ポリシーは、商用バージョンでのみトラフィックの視覚化機能を提供します。オープンソースのユーザーの場合、トラフィックの関係を理解せずにセキュリティ ポリシーを「盲目的に一致」させる必要があり、精度と効率が大幅に低下します。管理規模が大きくなるにつれて、ビジネスに適合し、最小権限の原則に準拠したセキュリティ ポリシーをカスタマイズすることがますます不可能になります。

同時に、大規模なコンテナ環境では、東西の接続関係が非常に複雑になります。多くの実践経験から、管理者が政策ルールを策定する際に「最初に目標を達成する」可能性は非常に低いことが証明されています。セキュリティ ポリシーでは通常、シミュレーション テスト、詳細な調整、および設計から実行までのその他の段階が必要になります。そうしないと、誤ったブロックが発生する可能性が高くなり、サービス間の呼び出しが直接失敗することになります。しかし、ネットワーク ポリシーの即時有効メカニズムでは、管理者の構成の難易度と試行錯誤のコストが非常に高く、ポリシーの発行と実行が妨げられます。

3) 管理操作の使い勝手が悪い

ほとんどのユーザーにとって、ネットワーク ポリシーの管理操作は使いにくいものです。たとえば、Namespace と Pod ラベルに基づいてのみポリシーを定義できます。コンテナ プラットフォームを標準化された方法で管理していないユーザーの場合、ポリシーの柔軟性は大幅に制限されます。別の例として、ポリシー定義は YAML ファイルを手動で編集して実装する必要があり、その結果、構成の効率が低下し、構成ミスのリスクが高くなります。これらの問題は、複雑なコンテナ環境で効果的なマイクロ分離戦略を構成することには役立ちません。

ハイブリッド アーキテクチャでは、クラウド ネイティブ環境のコンテナを管理できません。コンテナはワークロードの主流のタイプですが、クラウドネイティブへの変革が完全に完了した後でも、コンテナが仮想マシンインスタンスを完全に置き換えることはありません。つまり、ほとんどのユーザーのデータセンターでは、物理マシンインスタンス、仮想マシンインスタンス、コンテナが長期間共存することになります。ワークロードは異なるアプリケーションを実行するため、依然として密接な水平接続を持ち、マイクロ分離管理の範囲に均一に含める必要があります。ネットワーク ポリシーは、明らかに、コンテナー プラットフォーム内の分離制御にのみ適用されます。

まとめると、K8S の組み込みネットワーク ポリシーは、コンテナ プラットフォームでポリシーベースの内部トラフィック制御機能を提供できますが、単純な「ポリシー実行ポイント」のようなものです。実際、クラウドネイティブ環境でマイクロセグメンテーションを実装するのは非常に複雑です。現在のネットワーク ポリシーでは、設計から定義、運用、保守に至るまで、ポリシーのライフ サイクル全体を完全に管理することはできません。

2. ホストエージェントの形でのワークロードのマイクロ分離

ネットワーク ポリシーはクラウドにネイティブですが、困難な状況にあります。これは、クラウド ネイティブ環境でプロフェッショナルなセキュリティ機能の深さ、幅、使いやすさが求められていることを裏付けています。実際、クラウド ワークロードのマイクロ分離保護は、クラウド ネイティブ時代の産物ではありません。この技術は2015年にガートナーによって提案され、近年急速に主流の技術チャネルに導入されました。しかし、マイクロアイソレーションが始まった当初は、その分離対象は主にクラウドプラットフォーム内の仮想マシンインスタンスであり、コンテナはまだ広く使用されていませんでした。

新しいインフラストラクチャの革新的なテクノロジーとして、早期のマイクロセグメンテーションには複数の技術的なルートがあり、それぞれに長所と短所があり、対応する適用可能なシナリオがあります。クラウドベンダーは、ユーザー向けに自社のプラットフォームに適したセキュリティコンポーネントをリリースしており、これらはクラウド管理プラットフォームと緊密に統合できますが、サードパーティのクラウドプラットフォームへの適応性には明らかな制限があります。ファイアウォール ベンダーは仮想化プラットフォームに適応し、東西トラフィックをファイアウォール システムに誘導してアクセス制御を実装します。より成熟したセキュリティ機能を使用してトラフィックを検出および制御することもできますが、パフォーマンスに大きな問題があり、実際の効果は仮想化プラットフォームの互換性と適応レベルに左右されることがよくあります。独立したマイクロセグメンテーション ベンダーは、ホスト エージェント アプローチを使用して、ワークロード オペレーティング システムのホスト ファイアウォール プログラム (IPTABLES) を制御することにより、ワークロード指向の分離制御を実装します。これにより、ハイブリッド クラウド、マルチクラウド、さまざまなクラウド プラットフォームに完全に適応し、インフラストラクチャの独立性を最大限に実現できます。

ほとんどの K8S ネットワーク プラグインは、ノード ホスト カーネルの固有の機能を使用して、コンテナー プラットフォーム内でネットワーク転送を実装します。これにより、ホスト エージェント ベースのマイクロ分離システムがコンテナ環境に適応するための自然な技術的条件が提供されます。エージェントはコンテナ ノードのオペレーティング システムに展開され、そのカーネルのネットワーク転送を制御して、コンテナ間の通信のアクセス制御を実現します。したがって、比較的完全なマイクロ分離機能に基づき、コンテナ環境との自然な互換性に依存するホストエージェント形式に基づくマイクロ分離システムは、仮想マシンとコンテナが長期間共存するコンテナプラットフォームおよびハイブリッド環境にとってほぼ唯一の実現可能なマイクロ分離ソリューションです。

しかし、データセンターが「アプリケーションのコンテナ化」から「完全なクラウドネイティブ」へと進化した後も、このようなソリューションにはクラウドネイティブの概念に反する多くの欠点が残っていました。この問題の核心は、ノードにエージェントをインストールして展開する必要があることです。

K8S クラスターでは、Pod は最小のコンピューティング単位であり、Node は Pod のキャリアです。ノードのオンデマンド展開中は、エージェントは確立されたとおりに自動的に展開することはできません。代わりに、追加のインストールを実行する必要があり、必然的に DevOps プロセスが遅くなり、継続的な配信の効率が低下します。また、導入規模が大きくなるほど管理基準が厳しくなり、ノードインストールエージェント自体の管理権限の取得もかなり不便になります。

結局のところ、ホスト エージェント ベースのマイクロ分離ソリューションはコンテナ環境をサポートできますが、完全に「クラウド向けに生まれた」わけではなく、クラウド ネイティブ環境でのマイクロ分離の理想的な実現とはまだギャップがあります。

5. コンテナクラウドプラットフォーム向けセキュリティ分離ソリューション

一般的に、理想的なコンテナ クラウド プラットフォームのセキュリティ分離ソリューションは、次の条件を満たす必要があります。

1. クラウドネイティブ環境の特性に完全に適応

クラウド ネイティブの本来の目的は、クラウド コンピューティングの俊敏性と柔軟性という技術的メリットを最大限に引き出すことです。セキュリティ対策の使用は、クラウド ネイティブの固有の特性を犠牲にしてはなりません。セキュリティ機能をクラウド プラットフォームに組み込めるように、セキュリティはネイティブの考え方で構築する必要があります。

具体的には、クラウド ネイティブ セキュリティ ソリューションは、外部展開ではなく組み込みアプローチを採用する必要があり、セキュリティ機能は、クラウド ネイティブ環境のアプリケーションのように、オンデマンドで迅速に展開および拡張できる必要があります。クラウド プラットフォームのネイティブ リソースとデータを最大限に活用して、適応型セキュリティ ポリシーを実現できる必要があります。

したがって、分離ソリューションには、コンテナ化された展開と操作、適応型ポリシー計算などの機能があり、セキュリティ機能をネイティブな方法でクラウド プラットフォームに統合し、クラウド ネイティブ環境の俊敏性、柔軟性、弾力性、動的スケーリングの特性に完全に適応する必要があります。セキュリティをコンテナのライフサイクルと密接に同期させ、洗練されたアクセス制御機能を自動的にロードすることで、ユーザーのコンテナ プラットフォームの保護の「盲点」を排除するだけでなく、セキュリティ保護をビジネス アプリケーションにシフトします。

2. 信頼できる戦略的設計支援を提供する

クラウドネイティブ環境は、従来の IT アーキテクチャと管理モデルに大きな混乱をもたらしました。開発からテスト、運用、保守までのよりコンパクトなアプリケーション ライフサイクルでは、セキュリティ制御の設計と実装はビジネス チームの関心の範囲外になることがよくあります。セキュリティ担当者がセキュリティ対策をアプリケーション配信プロセスに統合することが難しい主な理由は、ビジネス構造と運用を理解していないことです。必要な情報がなければ、戦略をどのように設計するかという質問にも答えることができません。

クラウドネイティブ環境でマイクロ分離を実装するシナリオでは、グローバルな接続ステータスの概要を把握したり、ビジネスインタラクションを正確に整理したりできないため、ユーザーが従来のドメイン境界アクセス制御のようにセキュリティポリシーを事前に設定することは困難です。代わりに、ビジネスの本質に沿ったポリシー ルールを定義し、最小権限の原則に従うために、一定期間の学習、分析、モデリングを行う必要があります。このプロセス中、システムは視覚化とインテリジェント機能を通じて、セキュリティ戦略の設計に支援と利便性を提供する必要があります。

長年、メーカーによって「神格化」されてきた「可視化」技術は、ここ数年でむしろ「花瓶」のようなものになってきました。今日、可視化はマイクロアイソレーションの重要な機能となっています。 「制御可能」であるためには、まず「視覚化」する必要があり、これも「戦略支援設計」の具体的な表現です。

そのため、コンテナ クラウド分離ソリューションでは、ビジネスの観点から接続関係を可視化して分析する機能を提供する必要があります。マイクロ分離戦略の実装準備段階では、クラウドネイティブ環境の東西トラフィックを、全体状況を俯瞰してマイクロ分離を深く分析し、資産の分類やポリシー設計などの補助サポートを提供することで、マイクロ分離の実装の難易度をさらに低減します。

3. 完璧な戦略的管理能力を有する

クラウド ネイティブ環境でより効果的なセキュリティ制御を実現するには、より大規模で複雑な制御オブジェクトに対して、よりきめ細かく洗練されたセキュリティ ポリシーを実装する必要があります。これは、マイクロ セグメンテーション ポリシー システムにとって間違いなく大きな課題です。実際、コンテナ プラットフォームの強力なオーケストレーション機能により、セキュリティ ポリシーをロードして実行するためのポイントが不足することはありません。さらに重要なのは、ポリシー設計を正確に定義し、制御の意図を完全に実装できるようにするための、完全かつ体系的なポリシー定義フレームワークと管理および運用機能を備えることです。

クラウドネイティブ環境のマイクロ分離シナリオでは、まずセキュリティ ポリシーを IP およびホスト名から切り離し、ポリシー オブジェクトを定義するための新しいより豊富な方法をサポートする必要があります。セキュリティ ポリシーは、企業間または企業内、アウトバウンドまたはインバウンド、許可またはブロックなど、東西トラフィックに直面するシナリオに適応できる必要があります。セキュリティ ポリシーの実装では、マイクロ分離の実際の適用を考慮し、ポリシー設計の正確性と合理性を検証するために必要な効果シミュレーション方法を提供する必要があります。セキュリティ ポリシーのリリースは慎重にレビューでき、迅速なロールバック オプションなどを提供できる必要があります。

柔軟なポリシー定義オーケストレーションと完全な運用および保守管理機能を提供し、簡素化されたポリシー ロジック、柔軟なポリシー定義方法、豊富なポリシー有効性モード、完全なポリシー監査およびロールバック設計に反映され、クラウド ネイティブ環境における複雑なポリシー管理ニーズに対応します。専門的かつ体系的なマイクロ分離ポリシー管理と運用・保守機能により、ユーザーはより便利で使いやすいポリシー管理エクスペリエンスを得ることができ、データセンターでのゼロトラスト セキュリティ機能の実装が加速されます。

4. プラットフォームとクラスター間の統合管理

大規模なクラウドネイティブ環境では、物理マシン、仮想マシン、コンテナなど複数の種類のワークロードを同じプラットフォームで管理し、K8S クラスター全体の統一的な管理を実現するのが最適です。これにより、国内のほとんどのユーザーは、ハイブリッドクラウドやマルチクラウドなどの複雑なデータセンターシナリオにおけるマイクロアイソレーションの統一管理ニーズを満たすことができ、同社のフルビジネス可視化分析機能とフルビジネスアクセス制御機能を取得できるようになります。