安全なマルチクラウドアーキテクチャのためのKubernetesの実装

[[395137]]

この記事はWeChat公式アカウント「新チタン雲務」から転載され、喬炳成が翻訳したものです。この記事を転載する場合は、Xintai Cloud Service公式アカウントまでご連絡ください。

マルチクラウド環境では、次の 3 つの理由により、クラウド ワークロードのセキュリティ保護がより複雑になります。まず、セキュリティ機能はプロバイダーによって異なります。たとえば、Azure Sentinel は AWS CloudTrail とは異なります。

2 番目に、アクセス ログへのアクセス方法、ログに記録されるデータの種類、ポータルのリソースに対する管理アクセス権などのセキュリティ ポリシーの実装は、プロバイダーによって異なります。

3 番目に、運用上のセキュリティ タスクもプロバイダーに依存し、サービス提供のニュアンスを考慮に入れます。したがって、ワークロードが基盤となるセキュリティ サービスを直接使用すると、ロックインが発生する可能性があります。

これらの課題を軽減するために、IT リーダーはビジネス プロセスを組織のマルチクラウド戦略に組み込むことができます。 Kubernetes は、クラウド ワークロードの管理に使用できる人気のオープン ソース コンテナー オーケストレーション システムであり、クラウド プロバイダーのネイティブ セキュリティ サービスと顧客のセキュリティ ポリシー目標の間に抽象化レイヤーを提供します。

場合によっては、マルチクラウド オーケストレーション ツールは、セキュリティ サービスへのアクセス方法と使用方法の標準化を実施することで、ロックインを軽減することもできます。

さらに、これらの各ユースケースには、適切な状況下では潜在的なセキュリティ上の利点があります。ここでは、Kubernetes がマルチクラウド セキュリティ計画にどのように価値を付加できるか、また適切なデプロイメント オプションを評価して選択する方法について説明します。

マルチクラウド環境におけるKubernetesのセキュリティ上の利点

Kubernetes セキュリティの価値提案の基盤は、一般的な管理上の課題を自動化するフレームワークとしての機能にあります。たとえば、VM またはアプリケーション コンテナを展開する場合、オーケストレーションはプロビジョニング、プロビジョニング解除、オンデマンドのリソース スケーリング、およびシークレット管理などのワークロードの前提条件と依存関係を管理します。

マルチクラウド アーキテクチャにおける Kubernetes の価値を理解するには、ストア クレジットカードと銀行クレジットカードの違いを考えてみましょう。ストアカードでは、割引の増額やロイヤルティ プログラムなどの追加機能が提供される場合がありますが、利用できるのは 1 つのストアに限られます。一方、通常のカードでは、所有者はどこでも買い物ができますが、追加特典の一部またはすべては受けられません。

オーケストレーション プロバイダーは、保存されたシークレットの適切な機密性の強制、シークレットとワークロードへの適切なアクセス制御の確保、新しいワークロードが適切な構成でプロビジョニングされていることの検証など、セキュリティ上重要な要素を製品に組み込んでいます。

オーケストレーション プラットフォームに組み込まれたセキュリティ機能は、クラウド プロバイダーのネイティブ機能に代わる手段を組織に提供し、さらに重要なことに、オーケストレーション プラットフォームが理解できる機能を提供します。これにより、プロバイダーのネイティブ セキュリティ サービスが直接呼び出されないため、ベンダー ロックインが軽減されます。

ほとんどの場合、組織は基盤となるサービスを再実装することなくインフラストラクチャを再展開でき、代わりに別のプロバイダーの実装に移行できます。したがって、基盤となる実装は、ワークロードからは見えない形で必要に応じて交換できます。

同様に、ワークロードが移動する場合、オーケストレーション プラットフォームとの直接的なやり取りを可能にする自動化サポート、メトリック、カスタム ツールは、それらの機能がプラットフォームによってネイティブにサポートされている限り、他の環境に簡単にリダイレクトできます。

マルチクラウド アーキテクチャで Kubernetes をデプロイする方法

ビジネス プロセスをマルチクラウド セキュリティ戦略に適合させることを決定する場合、組織はベスト プラクティスを確立する必要があります。これには、スコープの定義、展開オプションの理解、展開モデルの選択という 3 つの主要な手順が含まれます。

スコープの定義

まず、マルチクラウド オーケストレーション ツールの使用事例を特定します。例:

• 多くのクラウド ホスティング環境とは対照的です。組織は 1 つのプロバイダーのみをサポートする必要がありますか、それとも異なるプロバイダーで複数のサービスを利用できる必要がありますか?
• 混合環境。オンプレミス環境とホストされたクラウド環境の両方をサポートする必要がありますか?
• コンテナと VM の混合環境。 VM とコンテナの両方に対して同じオーケストレーション サービスですか、それとも 2 つのうちの 1 つだけですか?

導入オプションについて学ぶ

範囲が定義されたら、IT リーダーは組織のニーズとユースケースに適した展開モデルを決定する必要があります。決定を下す前に、ホストされた Kubernetes サービス、オープンソース モデル、独自構築モデルという 3 つの主要なデプロイメント モデルとそれぞれの機能を比較してください。

1. マネージド Kubernetes サービス。多くのパブリッククラウドプロバイダーは、Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) など、サービスセットの一部として Kubernetes オーケストレーション機能を提供しています。

これにより、組織はサービスとしてのアプローチを使用してサービスに直接プロビジョニングできるようになり、社内で Kubernetes をセットアップおよび構成する負担が軽減されます。

2. オープンソース。 Kubernetes Operations (kOps) などのオープンソース オプションやその商用版を使用すると、組織はクラウド環境へのワークロードのプロビジョニングを自動化できます。

AWS Fargate などのツールは、クラウド ホスティング プラットフォーム全体で機能し、仮想プライベート クラウドまたはオンプレミスのローカル Kubernetes デプロイメントにもデプロイできます。

3. 自分でやってみよう。組織は、プロバイダーの柔軟なコンピューティング環境にオーケストレーション ソフトウェアを独自に導入できます。

展開モデルを選択する

マルチクラウドを保護するための適切な展開オプションについて合意に達するかどうかは、組織の目標、環境、セキュリティ目標によって異なります。

EKS、AKS、GKE などのマネージド Kubernetes サービスにより、迅速なデプロイが可能になります。これらのサービスは、標準化されたオーケストレーション メカニズムをバックグラウンドで使用することで、プロバイダー間でのワークロードの移植性を高めますが、クラウド サービス プロバイダーが基盤となるツールを独自の管理インターフェイスにラップするため、ある程度のベンダー ロックインが発生します。

これは、クラウド プロバイダーの管理 UI とセキュリティ モデルに慣れているセキュリティ運用スタッフにはメリットがありますが、異なるプロバイダーの複数の競合サービスにわたって管理ビューを標準化しようとする場合、このアプローチは最適ではありません。

kOps や商用オプションなどのクラウドに依存しないオプションは、マルチクラウド環境でホストされる Kubernetes サービスの欠点の一部を補うことができます。ただし、どのプロバイダーとどのサービスがサポートされるかに留意してください。

現在、kOps は AWS、Google Compute Engine (ベータ版)、Azure (アルファ版) をサポートしています。 IT リーダーは、提案された使用法を慎重に評価し、選択したツールが組織のサービス プロバイダーの使用プロファイルに基づいてサポートされていることを確認する必要があります。

DIY オプションでは、カスタム開発されたツールは最大限の移植性を持つため、最大限の柔軟性が得られます。このアプローチの欠点は、プラットフォームを展開および保守するために、運用スタッフからより多くの経験、プラットフォームに関する洞察力、および時間の投資が必要になることです。

結局のところ、特定の組織にとって正しい決定は、その組織の要件と用途に応じて異なることになります。他の計画タスクと同様に、事前に要件を理解し、展開オプションに対して体系的に分析して最適なアプローチを見つけます。

元のリンク: https://searchcloudsecurity.techtarget.com/tip/Implement-Kubernetes-for-multi-cloud-architecture-security