クラウドネイティブセキュリティ専門家の観察: コンテナクラウドセキュリティの現状と開発動向

コンテナ クラウド テクノロジーは、弾力性と効率性において大きな利点があるため、ますます主流の IT インフラストラクチャになりつつあります。ガートナーの予測によると、2025 年までにクラウド ネイティブ プラットフォームが新しいデジタル イニシアチブの 95% 以上の基盤を形成し、クラウド ネイティブ プラットフォームの大部分がコンテナ クラウド プラットフォームになると予想されています。コンテナクラウドの構築に伴い、そのセキュリティの重要性も高まり、セキュリティベンダーや各社のセキュリティ運用部門がこの方向への投資を開始しています。

コンテナクラウドのセキュリティは、コンテナ自体のセキュリティだけではなく、イメージのセキュリティ、オーケストレーション（K8sなど）のセキュリティ、マイクロサービスのセキュリティ、ホストオペレーティングシステムのリスクなども含まれます。その防御策には、ランタイムコンテナの検出と対応だけでなく、開発によって生成された成果物をチェックして、問題が発生する前に防止することも含まれます。セキュリティ・レフト・シフトは新しい概念ではありませんが、コンテナ・クラウドのセキュリティ構築では、従来のクラウド・プラットフォームのセキュリティ構築と比較して、ライフサイクル全体にさらに注意が払われます。

コンテナクラウドセキュリティの現状

• セキュリティリスクは楽観的ではない

「Sysdig 2022 クラウドネイティブ セキュリティおよび使用状況レポート」によると、実行中のコンテナの 75% 以上に高リスクまたは深刻な脆弱性があり、コンテナの 62% にシェル コマンドが含まれていることが検出され、コンテナの 76% がルート権限で実行されています。これまでに遭遇したユーザー事例では、コンテナ クラウドで kubelet に匿名でアクセスできるようになっている企業や、コンテナ クラウド プラットフォーム全体に保護対策がなく「裸」の状態になっている企業も数多くありました。多くの情報から、企業のコンテナ クラウドには大きなセキュリティ リスクがあり、慎重に扱う必要があることがわかります。

早くも 2018 年には、有名な自動車会社が AWS 上に展開したコンテナ クラスターに、ハッカーによってマイニング型トロイの木馬が埋め込まれました。 2021 年初頭、別の企業の Kubernetes クラスターが攻撃グループ TeamTNT によってハッキングされ、マイニング型トロイの木馬が埋め込まれました。 2021年4月1日、プログラム監査プラットフォームCodecovが攻撃を受けました。ハッカーは、Codecov の Docker イメージの作成プロセスにおけるエラーを利用して、スクリプトの権限を不正に取得し、変更しました。最終的に、彼らは情報を Codecov インフラストラクチャ外のサードパーティ サーバーに送信し、数万人の顧客に影響を与えました。

再セキュリティの観点から、2022年8月に実施された攻撃・防御訓練（HVV）では、コンテナ侵害に対する減点基準が明確化され、侵害されたコンテナ1つにつき10ポイントが減点されることになりました。クラスターとコンテナの数の関係に基づくと、クラスター全体が危険にさらされた場合、ポイントの損失は非常に深刻になります。

このことから、実際のネットワーク攻撃、攻撃と防御の訓練、コンプライアンス検査のいずれであっても、コンテナ クラウド セキュリティは重要な位置にあり、企業のセキュリティ構築部門はこれに十分な注意を払う必要があると結論付けることができます。

• 標準と仕様は成熟し続けている

初期のコンテナ クラウド セキュリティには国内の仕様と標準が欠如しており、メーカーとユーザーは K8S と Docker の 2 つの CIS ベンチマークしか参照できませんでした。しかし、需要が高まるにつれて、関連組織は業界の専門家を組織し、対応するセキュリティ構築と製品開発を導くための関連仕様を作成し始めました。

• 2020 年、CAICT はコンテナ セキュリティ標準を発表し、それに基づいた Trusted Container Cloud Certification を開始しました。
• 2021 年に、CAICT はクラウド ネイティブ アーキテクチャのセキュリティに関するホワイト ペーパーをリリースしました。
• 2022年、CSA Greater Chinaはクラウドネイティブセキュリティ技術仕様（CNST）をリリースし、公安部第三研究院と共同でクラウドネイティブおよびクラウドアプリケーションのセキュリティと信頼性の認定をリリースしました。
• 2022年、第三公安研究所は情報セキュリティ保護2.0のコンテナクラウドセキュリティ補足（コメント用草案）をまとめました。

また、各業界や企業でも、それぞれの特性に応じた規格を策定しています。

標準規格や仕様の導入と成熟は、その必要性や重要性を間接的に反映するとともに、製品の研究開発やユーザー調達の方向性を示すものでもあります。これらは強力な参照意義を持ち、業界における探索と迂回のコストを削減します。コンテナ クラウド セキュリティ製品にどのような機能が含まれるべきか、そしてそれがユーザーに対してどのような価値を生み出すべきかが、比較的明確になってきています。

• 製品間の熾烈な競争

今年のRSACイノベーションサンドボックスコンペティションのトップ10企業のうち、参加企業4社がコンテナクラウドセキュリティ関連分野を選択しており、このサブセクターの人気を実感できます。中国では約20社がこの分野に参入しています。その中には、Qi'anxin、Qiming、Green Alliance などの伝統的なセキュリティベンダーのほか、Qingteng などの新進気鋭の企業や、Xiaoyou などのスタートアップ企業も含まれています。今後さらに多くのメーカーが参入してくると筆者は予測している。コンテナクラウドセキュリティの今後の市場は有望であり、需要が本格的に解放される前にすでに競争は熾烈な段階に入っています。同時に、競争により製品機能の同質化がますます深刻化しています。

コンテナクラウドセキュリティ製品に関する議論

コンテナ クラウド セキュリティ分野のベテランとして、私は多くのベンダーのコンテナ クラウド セキュリティ製品を見てきました。また、私はベンダーのコンテナ セキュリティ製品の設計を個人的に主導し、その後、クライアントのコンテナ クラウド セキュリティの運用に切り替えました。過去数年間の私の個人的な経験に基づいて、参考までにいくつかのトピックを共有したいと思います。

• 3つのコア機能

ユーザーのニーズを踏まえると、コンテナクラウドセキュリティ製品に求められる機能としては、少なくとも「コンプライアンスチェック」「イメージスキャン」「侵入検知と対応」などが挙げられるでしょう。これは最も重要な要件であり、すべてのベンダーの現在のすべてのコンテナ クラウド セキュリティ製品が備えている機能でもあります。

イメージスキャン：「不変インフラストラクチャ」の特性により、コンテナのリークはイメージスキャンによって検出され、コンテナの強化もイメージ強化によって実現する必要があります。 Clair や Trivy など、画像スキャン用の優れたオープンソース ツールはいくつかありますが、これらのオープンソース ツールの機能は十分ではありません。一方では、スキャンの深度をコンポーネント レベルまで絞り込み、SCA 機能と組み合わせる必要があります。一方、スキャンされた脆弱性をどのように管理するか、どの資産が脆弱性の影響を受けるか、どの脆弱性を最初に修復する必要があるかは、コンテナ クラウド セキュリティの構築において考慮する必要がある問題です。一般的に市販製品の機能的完全性は優れていますが、ばらつきもあります。

侵入検知: 侵入検知は、ネットワーク セキュリティ攻撃および防御訓練において最も価値のある機能ですが、難しい機能でもあります。コンテナ クラウドが直面する攻撃方法は、ホストが直面する攻撃方法と非常に似ています。たとえば、リバウンドシェルやアカウント権限の昇格は一般的な方法です。両者の間には一定の違いもあるため、MITRE はコンテナ クラウド セキュリティの構築をガイドするために、コンテナ シナリオ用の ATT&CK フレームワークの別のバージョンを立ち上げました。しかし、実際に侵入検知を実行する場合、ほとんどのコンテナ セキュリティ製品は単一の指示に基づいてルールを照合することしかできず、コンテキスト接続に基づく包括的な分析を実行することはできません。当然、検出された攻撃方法を攻撃チェーンの特定の段階にマッピングすることはできません。さらに、ほとんどのコンテナ クラウド セキュリティ製品の侵入検出精度を向上させる必要があります。

コンプライアンス チェック: コンプライアンス チェックは簡単に実装できる機能です。製品の実装以上に注目すべきは、自社の状況に応じて適切なコンテナ クラウド セキュリティ ベースラインを確立する方法です。このセキュリティ ベースライン セットでは、k8s とコンテナーに加えて、コンテナー クラウド環境で実行されるデータベース セキュリティ ベースラインやその他の種類のミドルウェア セキュリティ ベースラインも考慮できます。

• マイクロセグメンテーション

2019年から2021年にかけてのホットな話題として、ゼロトラスト製品やゼロトラストソリューションが市場に多数登場しました。 3 つのコア技術の 1 つであるマイクロ分離は、当然ながらコンテナ セキュリティの分野にも欠かせません。基本的に、中国で主流のコンテナ セキュリティ製品はすべて、「マイクロ分離」の第 1 レベルのメニューを提供しており、これは多くの場合、Kubernetes 独自のネットワーク ポリシーまたは Linux 独自の IPtables を通じて実装されます。テクノロジーとして、NetworkPolicy はきめ細かいネットワーク層の分離を提供でき、理論的にはほとんどのシナリオで構成要件を満たすことができます。しかし、実際の運用では、面倒な設定作業が大量に発生するため、この機能の実装は非常に困難です。同じビジネス ソフトウェア内のさまざまな通信や、異なるビジネス ソフトウェア間のさまざまな通信を、ホワイトリストに事前に設定する必要があります。注意しないと、設定不足によりビジネスに影響が出る可能性があります。機密性のために可用性を犠牲にするのは価値がありません。したがって、既存のマイクロセグメンテーション製品がブロッキングに重点を置くのは不適切です。アラーム モードは、セキュリティ操作の促進により適しているはずです。

ステップ 1: ビジネス アプリケーションに基づいてコンテナーのネットワーク動作を調査し、ネットワーク動作モデルを構築します。

ステップ 2: モデルが構築された後、逸脱した交通に対してアラームが発行されます。

ステップ 3: 運用および保守担当者がアラームをチェックして、正確なアラームか誤報かを確認します。誤報の場合はモデルが修正されます。攻撃の場合はブロックされます。

上記のソリューションには 2 つの利点があります。まず、複雑な設定がないので、運用・保守担当者の作業負荷が軽減されます。 2 番目に、ビジネスの可用性に影響を与えることなくアラームのみを生成します。このソリューションにも課題と技術的な困難が伴います。構築されたネットワーク動作モデルが不正確な場合、大量の誤報が生成され、セキュリティ運用担当者が対処することが困難になる可能性があり、結果としてこの機能は依然として放棄されることになります。

• 展開フォーム

コンテナ クラウド セキュリティ製品には、ホスト エージェント、並列コンテナ、サイドカー コンテナ、エージェントレスの 4 つの展開オプションがあります。

Aqua、Twistlock、Stackrox、Neuvector などの海外のコンテナ セキュリティ製品は、ほとんどが並列コンテナの展開形式を採用しています。国内のセキュリティ ベンダーは、すでにホスト セキュリティ製品を持っている場合、ホスト エージェントを拡張して、1 つのエージェントでホスト セキュリティとコンテナ セキュリティの両方を担当する傾向があります。新しく設立されたコンテナ セキュリティ ベンダーの場合、並列コンテナ アプローチを採用してコンテナ セキュリティに重点を置く傾向があります。

ユーザーの観点から見ると、インストールするエージェントが 1 つ少ないということはリソースの使用量が少なくなるということであり、プラットフォームが同じということは管理コストが削減されることを意味します。したがって、ほとんどのシナリオでは、ホスト エージェントの展開方法の方が一般的です。しかし、並列コンテナには明確な支持者もいます。

• ホスト セキュリティの責任とコンテナ セキュリティの責任は異なる部門に属します。
• 調達したホスト セキュリティ製品にはコンテナ セキュリティ機能がないため、別途購入する必要があります。

サイドカー コンテナの展開形式を使用する製品ははるかに少なくなっています。一方では、より多くのリソースを消費するからです。その一方で、ビジネス ポッドにとっては多少侵入的であるため、この形式のセキュリティ製品は宣伝時に大きな抵抗に直面することになります。 Istio などのサービス メッシュ テクノロジーを使用する場合、Istio の現在の人気も非常に限られていることを認めなければなりません。

もう 1 つの興味深いアプローチは、Orca が代表的なベンダーであるエージェントレス展開方法です。 Orca のソリューションでは、クラウド ホストにエージェントはインストールされませんが、クラウド環境のブロック ストレージのスナップショットが取得され、そのスナップショットを通じて完全な「コンテキスト」が再構築され、セキュリティ スキャンと分析が実行されます。この技術的ソリューションは SideScanning と呼ばれ、その特徴は次のとおりです。利点と欠点は非常に明白ですが、この解決策はお勧めしません。

• エージェントは必要なく、ブロックストレージには「読み取り専用権限」のみが必要なので、業務に影響はありません。
• 迅速な展開、通常は 30 分以内に完了します。
• 完全なコンテキストを備えた資産の完全なカバレッジ。
• コントロール プレーンとデータ プレーンのセキュリティを含む複数のセキュリティ機能を統合します。
• リアルタイム分析ではなく、ほぼリアルタイムの分析。
• 分析能力のみあり、傍受やブロックはできない

まとめると、比較的主流のソリューションはホストエージェントと並列コンテナだと思います。これら 2 つのソリューションのどちらを選択するかについては、ユーザーは自分のシナリオに基づいて合理的な選択を行うことができます。

• オープンソースコミュニティ

クラウド ネイティブ コミュニティは非常に活発で、有名なスキャン ツールの Clair や Trivy、クラスター コンプライアンス チェックの Kube-bench、一般的なポリシー エンジンの OPA など、多数のコンプライアンスおよびセキュリティのオープン ソース プロジェクトが育成されてきました。昨年、Red Hat は StackRox を買収し、SUSE は NeuVector を買収し、これら 2 つの優れたコンテナ セキュリティ製品をオープンソース化しました。このような状況を踏まえると、コンテナセキュリティ製品の開発に対する技術的なハードルは大幅に下がり、このトラックに参加するメーカーの数は増加する可能性があります。セキュリティ開発能力を持つ企業の中には、オープンソースツールをベースに二次開発も行えるため、調達コストを節約できるところもあります。

ユーザーが商用製品を購入するか、オープンソースに基づいて独自の製品を開発するかは、多くの要因に関係しますが、ここでは詳細には説明しません。ただし、商用製品の開発者はオープンソースのセキュリティ ツールへの依存を減らすことをお勧めします。オープンソースコードとシンプルなパッケージングにより、新しい機能拡張を迅速に得ることができますが、ソースコードを詳細に研究しなければ、落とし穴を回避して本当に優れた製品を作成することは不可能になります。

コンテナクラウドセキュリティ開発動向

需要が拡大し、競争が激化するにつれて、コンテナ セキュリティ ベンダーは製品を最適化し続ける必要があります。ユーザーは、実際のセキュリティ運用からのフィードバックに基づいて、コンテナ クラウド セキュリティ構築の調整も行います。私の知る限り、コンテナ クラウド セキュリティ製品とコンテナ クラウド セキュリティ構築の両方にはまだ改善の余地がたくさんあります。

• 深い開発

コンテナ クラウド セキュリティは新たな分野横断型であるため、コンテナ クラウドとネットワーク セキュリティの両方を理解する人材が必要です。したがって、学習曲線はより急峻になります。これも才能不足につながります。この分野で優秀な人材を採用するのは、クライアントにとってもメーカーにとっても容易なことではありません。コンテナ セキュリティの人材が不足しているため、ユーザーとサプライヤーの両方が、製品のセキュリティ検出機能とパフォーマンスを詳細にテストするのではなく、機能の数で競争する際に表面的になりがちです。製品調達後のセキュリティ運用においては、防御の実効性よりも「事故を起こさないこと」を追求します。

今後、コンテナ クラウドのセキュリティとセキュリティ ニーズの高まりを理解する人が増えるにつれて、ほとんどのコンテナ攻撃を検出してブロックし、コンテナ クラウド上のデータ セキュリティを保護できるかどうかという問題の本質に焦点が当てられるようになります。この目標を達成するには、機能モジュールを追加することではなく、セキュリティ研究開発チームの蓄積と競争する必要があります。

• より多くの脆弱性を正確に特定する方法
• より既知の攻撃を正確に識別する方法
• 未知の攻撃から効果的に防御する方法
• 警報見逃し率と誤報率の両方を減らす方法
• 検出された問題を自動的に遮断/強化/修復できるかどうか

さらなる進歩を達成するには、現在のほとんどのコンテナ セキュリティ製品で使用されているユーザー モードのプロセス検出だけでは不十分です。おそらくカーネルモードの ebpf テクノロジが役割を果たすか、または「命令シーケンス」の検出によってより詳細な問題が明らかになる可能性があります。これにはさらなる調査と検証が必要です。

• 幅広い開発

2021年、ガートナーは新しいコンセプト「CNAPP（クラウドネイティブアプリケーション保護プラットフォーム）」を提案しました。ランタイム セキュリティに重点を置くコンテナ クラウド セキュリティとは異なり、CNAPP は、コード セキュリティ、ソフトウェア コンポーネント分析など、クラウド ネイティブ アプリケーションのライフ サイクル全体をカバーします。

CNAPP の提案は統合の概念を反映しています。ユーザーにとっては、分散したツールではなく統合プラットフォームを使用することで、より完全なセキュリティの観点が得られます。ただし、一部のユーザーの R&D 環境とテスト環境はネットワークを介して実稼働環境から分離されているため、このシナリオはすべてのユーザーに当てはまるとは限りません。コンテナセキュリティを構築する際、ユーザーは実際の状況に応じて適切な構築プランを選択できます。

結論

要約すると、コンテナ クラウド セキュリティの分野は大きな課題に直面していますが、チャンスもたくさんあります。しかし、それがますます重要になり、より良くなることは間違いありません。関心のある読者は、コンテナ クラウド セキュリティの将来の開発パスをより明確にするために、ぜひ一緒に議論してください。

Liu Bin 氏は、清華大学工学管理学修士、China Mobile Information のクラウド ネイティブ セキュリティ専門家、中国情報通信研究院のコンテナ クラウド ネイティブ セキュリティ仕様の主要著者の 1 人、クラウド セキュリティ アライアンス (CSA) の専門家メンバーであり、以前は Xiaoyou Technology の製品ディレクターを務めていました。彼は、EXIN DevOps Master、PMP、CCSK、CISP、AWS SAP などのさまざまな認定資格を取得しており、セキュリティ製品とソリューションの分野で 10 年以上の調査と実践経験を持っています。

China Galaxy Securities のアーキテクトである Wang Zhaohui 氏は、コンテナ クラウド、マイクロサービス、DevOps、データ ガバナンス、デジタル トランスフォーメーションなどの分野に重点を置いており、関連テクノロジーに対する独自の理解と洞察力を持っています。彼はソフトウェアの企画と設計に長けており、「プラットフォーム統合」という彼のコンセプトはますます認知され、実証されています。コンテナプラットフォーム構築、マイクロサービス技術、DevOps、デジタルトランスフォーメーション、データガバナンス、ミドルオフィス構築などをテーマとした技術記事を多数発表しており、幅広い注目と評価を得ています。