クラウドネイティブ セキュリティ アーキテクチャ設計のベスト プラクティス

クラウドネイティブテクノロジーは、その高い効率性、安定性、迅速な対応力により、企業のビジネス発展を推進し続けており、企業のデジタルビジネスアプリケーションにおけるイノベーションの中核的な原動力となっています。しかし同時に、クラウドネイティブ環境におけるさまざまなセキュリティリスクも増加しており、クラウドネイティブ環境におけるセキュリティアーキテクチャ設計ソリューションを検討し始めている企業が増えています。

先日、51CTOコンテンツセンターが企画・開始した[T·TALK]シリーズ活動の第8回では、Xiaoyou TechnologyのテクニカルディレクターであるBai Liming氏を特別に招待し、「クラウドネイティブセキュリティアーキテクチャ設計のベストプラクティス」について基調講演を行っていただきました。クラウドネイティブの開発動向、セキュリティリスク、セキュリティアーキテクチャ設計の紹介に重点を置いています。 【T·TALK】でも、この号でシェアした素晴らしいコンテンツをまとめて、皆さんにインスピレーションをお届けできればと思っています。

​

クラウドネイティブ開発のトレンド

2013 年に、Pivo​​tal はクラウド ネイティブの概念を初めて提案しました。 2015 年に、Pivo​​tal は自社の書籍で初めてクラウド ネイティブの 5 つの要素を正式に定義しました。

• クラウドネイティブアプリケーションの12の要素に準拠する
• マイクロサービス指向アーキテクチャ
• セルフサービスアジャイルアーキテクチャ
• APIベースのコラボレーション
• アンチフラジャイル

上記の 5 つの特性を満たすアプリケーションがクラウド ネイティブ アプリケーションです。

Cloud Native Computing Foundation (CNCF) は 2015 年に設立されました。設立当初、CNCF はクラウド ネイティブを次のように定義しました。

• アプリケーションのコンテナ化
• マイクロサービス指向アーキテクチャ
• コンテナオーケストレーションとスケジューリングのアプリケーションサポート

上記の 3 つの特性が満たされていれば、それはクラウド ネイティブ アプリケーションです。

2018 年、クラウド ネイティブ テクノロジーの発展に伴い、CNCF は最新のクラウド ネイティブ インフラストラクチャ機能に基づいてクラウド ネイティブを再定義しました。

• コンテナ化
• サービスメッシュ
• マイクロサービス
• 不変のインフラストラクチャ
• 宣言型API

上記の 5 つの特性が満たされていれば、それはクラウド ネイティブ アプリケーションです。

クラウドネイティブ テクノロジーが変化し続けるにつれて、コンテナ化によってオペレーティング システムの機能と特徴がさらに合理化されます。クラウドネイティブ定義における不変のインフラストラクチャの要件を満たすために、クラウドネイティブ オペレーティング システムが誕生しました。コンテナ関連の依存ライブラリのみを保持し、コンテナ クライアントをパッケージ マネージャーとして使用する、高度に合理化されたカーネルが特徴です。

クラウドネイティブ オペレーティング システムの共通の概念は、すべてのプロセスをコンテナー内で実行する必要があるということです。オペレーティング システムのホスト マシンにアプリケーションをインストールすることはできないため、オペレーティング システムが完全に不変であることが保証されます。これはいわゆる不変インフラストラクチャであり、オペレーティングシステムの将来の開発動向でもあります。

初期のインフラストラクチャは物理マシン上で実行されていましたが、インフラストラクチャが変化するにつれて、アプリケーションは仮想マシンで実行されるようになりました。コンテナ時代では、すべてのアプリケーションはコンテナ内で実行されます。最新の人気トレンドとして、現在、国内外で、対応するインフラストラクチャ アーキテクチャであるサーバーレス テクノロジーを提供しているクラウド ベンダーがいくつかあります。

物理マシンの時代では、インフラストラクチャは通常、年単位で計算されます。物理マシンがコンピューター室に設置されると、1 年または 5 年後に取り外されます。後続の仮想マシンでは、動作単位として月が使用されました。コンテナ時代では、アップデートごとに新しいコンテナを再構築する必要があるため、コンテナのライフサイクルは日単位で測定されます。サーバーレス時代では、機能の仮想化は数分で測定されます。

コンテナ化の出現後、コンテナ技術の標準化のプロセスが加速されました。 DevOps とコンテナは互いに補完し合います。コンテナプラットフォームを適用する場合、リリースプロセスを加速するために DevOps 開発モデルに進化する必要があります。コンテナ化の利便性により DevOps が推進され、コンテナは反復処理を高速化するために DevOps に依存しています。これが開発モデルの現在の進化の傾向です。

コンテナをユニットとして使用する場合、クラウド ネイティブとサービスはネットワーク境界になります。クラウドネイティブ分野では、IPという概念はありません。クラウドネイティブのすべての IP は動的であり、従来のファイアウォールで対応する IP アドレスを構成することはできません。クラウドネイティブでは、コンテナ サービスは毎日更新されます。 IP アドレスが更新されるたびに新しい IP アドレスになり、以前に構成されたネットワーク ポリシーは無効になります。

物理マシンの時代は、物理マシンを店頭に置くことが困難だったため、通常は 1 台の物理マシン上で複数のアプリケーションが実行されていました。仮想マシンの時代では、サービスの可用性を向上させるために、通常、単一のサービスが単一の仮想マシンに分割されます。現在、サービス インターフェイスが増加し、マイクロサービスへの依存度が高まっているため、インターフェイスをマイクロサービス アーキテクチャに進化させる必要があります。

Weibo を例にとると、ホット イベントが発生すると、業務の復旧が達成されるまでに、物理マシンと仮想マシンの両方を何時間もかけて構築する必要があります。コンテナ化されたシナリオでは、コンテナは数秒で起動します。これは、物理マシンや仮想マシンのシナリオよりもはるかに高速です。そのため、Weibo がコンテナ アーキテクチャに進化した後は、ホット イベントによってクラッシュすることはほとんどありません。もちろん、K8S プラットフォームの自己修復能力と動的な拡張と縮小もこれに大きく貢献しました。

初期のコンテナ ランタイムでは Docker を使用していたため、コンテナは Docker と同一視されることがよくありました。コンテナ自体は 4 つのモジュールに分かれており、Docker も 4 つのインターフェースに分かれています。ただし、Docker は完全な開発スイートであるため、K8S は動作時にランタイム側のみを使用します。そのため、運用効率化の要請から、K8S はバージョン 1.20 で段階的に Docker Shim のサポートを中止し、Docker Containerd を直接使用するようになりました。

Containerd であれ Docker であれ、セキュリティ機能のサポートは完全ではありません。 Cri-o テクノロジーは、関連するセキュリティ要件を満たすことができます。デーモンプロセスは必要ありません。各 Cri-o プロセスには、サービスを実行するための独立したプロセス (親プロセスと子プロセス) を設定できます。コンテナ分野における今後のトレンドは、セキュアテクノロジーのコンテナ化を含む、基盤となるインフラストラクチャのセキュリティです。

​

クラウドネイティブのセキュリティリスク

現在、クラウド ネイティブ分野で考慮する必要がある主なセキュリティ上の問題は 5 つあります。

• 画像のセキュリティ
• 画像リポジトリのセキュリティ
• クラスター コンポーネントのセキュリティ
• コンテナネットワークのリスク
• マイクロサービスのリスク

その中でも、ミラーのセキュリティリスクは比較的広範囲に及んでいます。クラウド ネイティブ分野では、インフラストラクチャのセキュリティと比較して、パフォーマンスの最適化とインフラストラクチャのコンテナ化に重点が置かれています。これは、現在の DockerHub イメージのうち、51% に高リスクの脆弱性があり、80% に中リスクおよび低リスクの脆弱性があることを意味します。企業がイメージを構築する場合、90% のケースで DockerHub からイメージをダウンロードする必要があります。

イメージリポジトリに関して言えば、企業がすべての R&D イメージとビジネスイメージをパブリックイメージリポジトリにアップロードすることは不可能です。ソースコードはエンタープライズ ウェアハウスに保存する必要があります。ただし、企業の倉庫にはセキュリティ上の脆弱性が存在する可能性もあります。これらの脆弱性がハッカーに悪用されると、ウェアハウス内のイメージが直接置き換えられることになります。ノードからイメージをプルすると、ハッカーによってトロイの木馬ウイルスに感染したイメージが取得される可能性があり、これも非常に危険です。

クラスターコンポーネントのリスクに関しては、Docker自体に現在111件の脆弱性があり、K8Sには65件、Open Shiftには35件の脆弱性があり、Cri-o、Containerd、Kata Containerなどの他のコンテナランタイムには合計45件の脆弱性があります。クラスター コンポーネントの脆弱性は比較的まれですが、存在します。

ハッカーが上記の脆弱性を利用してクラスターに侵入すると、クラスター内の他のコンテナにもアクセスし続けることになります。物理ファイアウォールはクラスター外部のトラフィックのみを保護できます。 K8S には、クラスター内のトラフィック用のオーバーレイとアンダーレイという 2 つのネットワーク アーキテクチャがあります。しかし、オーバーレイであれアンダーレイであれ、従来のファイアウォールではクラスター内の攻撃から保護することができず、クラスター内のネットワーク リスクとなります。

ビジネス イメージの脆弱性は、組み込みイメージ コンポーネントの脆弱性という別の問題を引き起こす可能性もあります。開発者が参照する API や使用する開発フレームワークに脆弱性がある場合、開発者が開発コンポーネントをイメージにパッケージ化するときにこのような問題が発生します。これまで広く影響を及ぼした Spring フレームワークの 0-day 脆弱性は、インフラストラクチャの脆弱性によって引き起こされ、国内企業の約 90% に影響を与えました。この種のリスクは通常、R&D によって導入され、マイクロサービスのリスクとなります。

クラウドネイティブセキュリティアーキテクチャ設計

以前のインフラストラクチャは、主にファイアウォールと物理的なセキュリティによって維持されていました。コンテナ コンピューティング環境に関しては、コンテナのランタイム セキュリティとイメージ セキュリティには専門的なコンテナ セキュリティ保護が必要です。コンテナのアプリケーション セキュリティには、マイクロサービス検出とサーバーレス保護に対応するコンテナ セキュリティが必要です。

クラウドネイティブのシナリオでは、R&D セキュリティ システムをクラウドネイティブ セキュリティ分野に組み込む必要があります。これは従来のセキュリティとは異なります。 R&D 担当者は、安全なシステムの構築に参加し、R&D プロセス中にクラウドネイティブのデータ セキュリティと一部のセキュリティ管理権限に常に注意を払う必要があります。

Xiaoyou の現在のコンテナ セキュリティには、多くの組み込み戦略、機械学習戦略、廃棄戦略、イベントがあります。機能の 1 つは、スケジュール ファイルの監査です。開発者のコ​​ード リポジトリに直接接続し、コード リポジトリから既存のすべての Dockerfile ファイル、YAML ファイル、オーケストレーション ファイルを読み取ることができます。そして、Dockerfile ファイルを通じて構文を推測し、コマンドの問題を見つけます。

監査が完了した後、問題があれば研究開発担当者に報告され、イメージ構築が禁止されます。セキュリティ上の問題がない場合は、変更のフィードバックを直接行い、変更が完了した後にイメージを生成します。このとき、イメージも Dockerfile にリバースされ、イメージと Dockerfile ファイルの比較が行われます。 Dockerfile ファイルが改ざんされていることが判明した場合も警告が発行されます。

また、イメージを元に動作するコンテナサービスもリバースされ、コンテナが依存するイメージが正しいか、イメージ内で動作しているプロセスがDockerfileファイルにパッケージ化されたプロセスと同じ名前かどうかなどが検知されます。不整合が見つかった場合は、業務に危険が及ぶことを知らせるアラームが発せられます。

クラウドネイティブは不変です。不変のインフラストラクチャには、基盤となるオペレーティング システムとイメージが含まれるため、イメージも不変です。 Dockerfile ファイルがどのようなものであっても、ビルドされるイメージはそれに対応している必要があります。イメージがどのように見えるかに関係なく、実行中のコンテナがこの範囲を超えることは絶対にありません。

もう 1 つの機能は、コード リポジトリから YAML オーケストレーション ファイルを直接読み取ることです。オーケストレーション ファイルの権限制限を設定します。放棄された構文、誤った構文、高リスクのコマンドなどの危険なパラメータがオーケストレーション ファイル内に見つかった場合、アラームが発行されます。これを実施する目的は、セキュリティ、運用、保守と研究開発を連携させることです。クラウドネイティブのセキュリティは、運用・保守担当者、開発者、セキュリティ担当者の連携によって対処する必要があり、セキュリティ部門だけの問題ではありません。

市場にはオープンソースのイメージコンポーネントスキャンが数多く存在します。 Mirror World コンテナ セキュリティ保護プラットフォームのオープン ソース バージョンと商用バージョンとの最大の違いは、カスタム ルールと脆弱性ライブラリです。オープンソース脆弱性ライブラリは、オープンソース CBE 脆弱性ライブラリに基づいて実装されており、中国の CNNVD 脆弱性ライブラリをサポートしています。中国のCNNVDは入手に協力が必要であり、通常のオープンソースメーカーはCNNVDの脆弱性ライブラリを入手できません。これがオープンソースと商用の最も大きな本質的な違いです。

商用版では、信頼できるイメージ、ベースイメージの識別、ホストイメージのスキャンなど、脆弱性に対するカスタム機能はオープンソース製品では利用できません。イメージリポジトリにはセキュリティ上のリスクが伴います。企業が社内セキュリティ機能を構築する場合、イメージ リポジトリを自らスキャンして脆弱性を探す必要があります。 Xiaoyou は Harbor のセキュリティ脆弱性全体のメンテナンスに携わっているため、この点では一定の優位性があります。

クラスター コンポーネントにもリスクがあります。クラスターコンポーネント自体のリスクを発見するには、まずクラスター自体を組み合わせて、脆弱性ライブラリと脆弱性バージョンに基づいて比較する必要があります。同時に、API インターフェースの脆弱性や権限の脆弱性はバージョン比較では検出できないため、クラスターコンポーネント全体の脆弱性のリスクを確認するには、何らかの POC 検査方法が必要です。

クラスター全体の独自のコンポーネントの構成をスキャンし、構成の独自の権限をスキャンします。最も初期の K8S では、認証権限はデフォルトで有効になっていませんでしたが、現在はデフォルトは https になっています。さらに、監査ログが有効かどうかなどの機能をクラスターのセキュリティに基づいてスキャンし、コンプライアンス チェックのベースラインを構成する必要があります。

クラウドネイティブのマイクロサービス シナリオでは、サービスの分割により指数関数的な成長が実現します。このとき、セキュリティ ソフトウェアは、マイクロサービスを自動的に検出し、サービスの種類を識別して、対応する方法を使用してサービス内の脆弱性を自動的にスキャンして検出する必要があります。これは非常に労力を節約できる方法です。

コンテナの実行後のコンテナ内のセキュリティ テストは、2 つのモードで実行できます。 1つは、コンテナ内のすべてを画像から学習することでコンテナの動作を固定化する機械学習です。同時に、コンテナのファイルの読み書き、プロセスの開始と停止、アクセス呼び出しを学習し、実行中のすべての動作をキャプチャして動作モデルに記録し、コンテナの動作モデルにまとめます。コンテナ内で実行されるすべてのトラフィックは正常トラフィックとみなされ、排出されるすべてのトラフィックは異常トラフィックとみなされます。

しかし、学習には時間がかかり、学習プロセス中に攻撃に遭遇したりコマンドを実行したりすると、結果が歪んでしまいます。この目的のために、攻撃モデルを組み込んだ戦略を立てることができます。組み込みのセキュリティ戦略に違反する動作が見つかった場合、その動作は直接除外されます。このように、機械学習の行動学習を組み合わせることで、学習プロセス中に攻撃が発生するのを防ぎながら、ゼロデイ脆弱性から防御することができます。組み込みのブラックリスト戦略と機械動作学習の組み合わせにより、機械ランタイム セキュリティ検出の完全なクローズド ループを実現できます。これは現在、コンテナ セキュリティ ランタイムのベスト プラクティスです。

クラウドネイティブ分野では、クラウドネイティブマイクロアイソレーションは以下の機能を実現する必要があります。まず、アクセス関係の可視化です。クラウドネイティブの分離は本質的にゼロトラストのリスクを伴うためです。 K8S には IP の概念がなく、すべてがラベルに基づいています。ラベルは研究開発担当者や業務担当者が割り当てたタグであり、ラベルに基づいて動的にマイクロアイソレーションが実行されます。そのため、学習関係に基づいてコンテナ戦略を自動的に生成し、その戦略をプレビューする必要があります。

戦略学習が完了して確認されるとプレビューモードに入り、プレビュー時間を設定できます。一定期間内は、通常のトラフィックはすべてブロックされません。トラフィックがポリシーの影響を受けることが判明した場合、警告が発行されます。研究開発担当者または業務担当者が手動で判断します。ビジネス トラフィックが安全である場合、機械学習モデルは編集され、モデルから除外されます。

一定期間が経過しても他のトラフィックが見つからない場合、学習したポリシーは通常のトラフィック パターンにまったく影響を与えず、すべてのトラフィック攻撃を防御できます。このとき、「ポリシー実行」をクリックすると、本番業務に影響を与えずに、自動的に学習したポリシーを本番環境に適用できます。

最後に、クラウド ネイティブ分野では、クラウド ネイティブ セキュリティ ソフトウェア プラットフォームは 3 層アーキテクチャに準拠する必要があるという重要な点があります。第 1 層は管理層であり、すべてのクラスターが収束できるように、管理プラットフォームをタスク センターから分離する必要があります。

イメージ ウェアハウス内のデータ量が大きすぎる場合は、ネットワーク帯域幅に依存してイメージをプルするのではなく、スキャンをウェアハウス イメージに直接統合し、スキャン中にストレージ パスを直接読み取ることができます。これにより、ネットワーク使用量とディスク IO 使用量が大幅に削減され、直接読み取ることができます。これは現時点でのコンテナ セキュリティに最適なアーキテクチャ設計です。

クラウドネイティブセキュリティのベストプラクティス

クラウドネイティブ環境での DevSecOps 設計は、主に 3 つの部分に分かれています。最初の部分は構築段階です。ここで、Xiaoyou Technology は、強化されたすべての技術イメージを含むゴールデン イメージ ウェアハウスを提供します。 R&D 担当者は、ゴールデン イメージ リポジトリから直接プルしてビジネス イメージを構築できます。

Xiaoyou は CNNVD と公式に提携しており、脆弱性データベースは更新後に直接同期されます。 Xiaoyou は、毎日の脆弱性の更新に基づいて、独自のゴールデン ミラー リポジトリをリアルタイムで維持します。さらに、Xiaoyou には独自のスキャナーと、最新の脆弱性やゼロデイ脆弱性を研究する専門のセキュリティ研究者がいます。

企業では、2 つのイメージ リポジトリを分割し、クラスター内の実稼働イメージ リポジトリに対して信頼判断を設定することをお勧めします。これにより、ハッカーがクラスターに侵入し、独自のビジネス コンテナーを直接プルダウンすることを効果的に防ぐことができます。 K8S インターフェースを使用して、ハッカー自身のイメージをすべて取得し、すべての侵入を直接実行します。この状況は完全に回避できます。

イメージのスキャンフェーズでは、ビジネス開発のためのアプリケーション層のスキャン構成とスキャン構成を実行します。脆弱性が見つかった場合、同期はブロックされます。本番環境では、信頼判定を設定し、自社環境のミラーリポジトリを使用するかどうかなど、プラットフォーム上で任意に設定できるすべての条件を信頼判定に統合することができます。

プラットフォーム上のいくつかの機能を使用して、クラスターの独自のコンポーネントとマイクロサービスにおける脆弱性のリスク評価も実行できます。イメージの脆弱性スキャンと分析を例にとると、イメージをいくつかの部分に分解して、各イメージが誰に依存しているかを識別できます。技術的影響コンポーネント、ソフトウェア コンポーネント分析、ソース コード スキャンと開発セキュリティ スキャン、アプリケーション脆弱性スキャンなど。

コンテナ セキュリティ プラットフォームは、攻撃インシデントを検出すると、インシデントの前、最中、後に包括的なセキュリティ対策を講じます。クラスター全体が事前に評価および強化され、強化が完了した後にすべての行動学習が開始されます。このプロセスでは、脅威チェックとゼロデイ防御が実行され、すべてのアラームがリアルタイムで発行されます。

攻撃が発見されると、まずイメージの実行がブロックされます。 R&D 段階では、画像のアップロードがブロックされる可能性があります。ウェアハウスフェーズでは、イメージのダウンロードがブロックされる可能性があります。本番環境ではイメージの実行がブロックされる可能性があります。コンテナが実行された後、イメージは分離戦略を自動または手動で実行できます。自動処理と手動処理のルールを設定します。

クラウドネイティブ ネットワーク セキュリティ プランニングでは、異なるクラスター間のネットワーク ドメインが異なるため、各クラスター間の物理ネットワークではデフォルトでオーバーレイ ネットワーク プラグインが使用されます。したがって、ネットワーク セキュリティ ドメインに基づいて、クラスター間のネットワーク ドメインが自然に分割されます。

クラウドネイティブのマイクロ分離は、IP ブロッキングをサポートし、ゼロトラストおよびラベル ブロッキング方式と互換性があり、IP 構成をサポートする必要があります。クラウドネイティブ セキュリティ プラットフォームはこのように計画されています。同時に、従来のセキュリティファイアウォールを有効活用することも必要です。セキュリティ保護のためには、専用のクラウドネイティブ セキュリティ ファイアウォールを使用するだけでなく、従来のファイアウォールと組み合わせる必要があります。

ゼロデイ攻撃の防止は、次の 5 つの次元に基づいてモデル化できます。

• コンテナ内の動作を学習してセキュリティモデルを構築する
• モデル外のプロセス、ファイルアクセス、異常なネットワーク接続、システムコールが検出されると、相関関係を通じて製品リスクイベントリストが分析されます。
• 人間の応答処理、異常な動作をタイムリーにブロックしたりエラーを修正したりすること
• テスト環境でモデルを生成し、再学習せずに本番環境に直接適用する
• 脆弱性ゼロ、ゼロデイリスクをサポート

プロセスの開始と停止、および特定の学習サイクル内でプロセスによって読み書きされるファイルはすべて学習する必要があります。例えば、学習サイクルの終了後、このようなデータベースに対して突然ブルートフォース攻撃を試み、短期間でネットワークエラーや検証エラーが大量に発生した場合、学習仕様を満たしていないと直ちに判断されます。システムコールと構成を含みます。

最初の 4 つの次元はすべて、すでに実行されているコンテナの動作を学習することに関するものであり、最後の次元は、実行前の動作を学習し、実行前の状態を予測することに関するものです。これらは学習の 5 つの側面です。さらに、ゼロデイ攻撃を防ぐために、履歴コンテナと以前のすべてのコンテナを記録することで学習が行われます。

​

ゲスト紹介

Lianzhong Gamesのクラウ​​ドネイティブプラットフォームの元責任者であるBai Liming氏は、DevSecOpsの研究と構築で7年の経験を持ち、現在はXiaoyou Technologyの技術パートナーを務めています。彼は中国初のクラウドネイティブ セキュリティ製品の中核設計者であり、公安部の「レベル保護 2.0」および中国情報通信研究院の「クラウドネイティブ アーキテクチャ セキュリティ白書」の主な起草者です。