Kubernetesはランサムウェアの影響を受けないわけではなく、イルミオがどのように役立つか
ランサムウェアはKubernetesでは問題ありませんよね?コンテナ 構造は非常に動的で一時的なものであるため、ランサムウェアがポッドをハイジャックし、名前空間間で悪意のあるペイロードを横方向に伝播しようとするリスクはほとんどありません。ポッドは非常に動的にスピンアップおよびスピンダウンするため、Kubernetesではランサムウェアはほとんど問題にならないため、私のクラスターはこの特定のサイバーセキュリティの脅威から安全ですよね?
残念ながら、この仮定は何度も間違っていることが証明されています。ランサムウェアは、Kubernetesではコンテナクラスターの外部とは異なる動作をする傾向がありますが、DevSecOpsアーキテクトが無視できない非常に現実的なサイバーセキュリティリスクです。ランサムウェアはKubernetesクラスターに非常に現実的な損害を与える可能性があり、修復の最善の形態は予防です。
イルミオは、ランサムウェアがKubernetesクラスターを乗っ取るのを防ぎ、組織がニュースに登場する次のサイバー攻撃の被害者になるのを防ぐことができます。
ランサムウェアがKubernetesでどのように伝播するか
コンテナ以外のワークロードでは、ランサムウェアはホストを乗っ取り、開いているポートを探します。多くのワークロードで既定で開いている一般的なポートは、RDP、SSH、SMB です。ランサムウェアがこれらのポートを介して接続を偽装し、隣接するホストへの接続を確立することは簡単です。接続が開くと、ランサムウェアは 悪意のあるペイロード を次のホストにすばやく配信し、それを制御し、開いているポートを探し、隣接するすべてのホストでこのプロセスを非常に迅速に繰り返すことができます。

ホスト間のこの伝播は、ほとんどの検出と対応のマルウェア保護ソリューションが識別して対応できるよりも速く発生する可能性があります。やがて、インフラ全体が人質に取られる可能性があります。
Kubernetesでは、ホスト(「ノード」とも呼ばれます)は、コンテナコードを実行する仮想マシン(VM)またはベアメタルホストです。これらは、ノードの基盤となるオペレーティング システム (OS) の上に抽象化レイヤーを作成します。クラスターは、ポッドとサービスが名前空間に関連付けられている場合に作成され、その名前空間には、その中で実行されているアプリケーションに必要なすべてのコードとライブラリが含まれています。名前空間内の構造は動的です。コンピューティングリソースが水平方向にスケーリングされると、ポッドはスピンアップしてコードを実行し、その後すぐに再びスピンダウンし、後で別のIPアドレスでスピンアップされます。
ポッドの有効期間は非常に短い場合があり、ほとんどのポッドはRDPやSSHなどのオープンポートを実行しません。これは、ポッドがこれらのプロトコルを使用して他のポッドと通信する傾向がないためです。したがって、ランサムウェアはクラスター内ではほとんど関連性がないと認識されることがよくあります。
ランサムウェアはKubernetesにおける大きな脅威です
ただし、 ランサムウェア は、Kubernetesクラスターですぐにサイバー災害になる可能性があります。悪意のあるコードは、コード開発ライフサイクルの早い段階で導入される可能性がありますが、まだ実行されていないため検出されません。悪意のあるペイロードは、公開された API、脆弱な認証設定、パッチが適用されていないソフトウェア、またはおそらく最も一般的なリスクである設定の誤りを介して Kubernetes クラスターに導入される可能性もあります。
サイバー脅威は、ソフトウェアサプライチェーンのどこにでも導入される可能性があります。たとえば、コンテナのイメージがオープンソースリポジトリからダウンロードされた場合です。クラスター内で実行すると、そのイメージには、Pod から基盤となるノードに実行して「エスケープ」できる埋め込みコードを含めることができます。次に、その基盤となるノードにランサムウェアを展開します。その時点で、ランサムウェアはそのノードをハイジャックし、オープンポートを介して隣接するノードへの接続を確立し、脅威がKubernetesクラスターをホストする基盤となるすべてのノードを迅速にハイジャックまたは暗号化できるようにします。
これにより、ワーカー ノードで実行されているアプリケーションが「ブリック」状態になり、事実上シャットダウンする可能性があります。コードが基盤となるマスターノードにエスケープすると、Kubernetesクラスターのコントロールプレーンがハイジャックされ、クラスター全体がブリックされるリスクがあります。コード開発ライフサイクルの早い段階で発生した小さな問題は、すぐに大きな災害になる可能性があります。
このタイプのマルウェアの例は、2021年3月に発見された Siloscapeです。ほとんど文書化されていないスレッドプロセスの脆弱性を利用して基盤となるノードにアクセスし、kubectlにアクセスしてコマンドを実行し、それ自体を隣接ノードに分散させることができます。これは、Kubernetesノードのコントロールプレーンを保護し、他のプロセスによってアクセスを制限する必要がある理由の顕著な例です。イルミオは、ホスト上の特定のプロセスへのアクセスを強制し、それらにアクセスできるユーザーを制限できます。
イルミオはKubernetesのランサムウェアからプロアクティブに保護できます
Illumioは 、Kubernetesクラスターと基盤となるノードの両方内でワークロード通信を強制します。
Kubernetes クラスター内では、 Illumioは、名前空間間、または名前空間とイングレスコントローラーの外部のワークロード間の通信を強制し、ワークロード間の不必要な通信を防ぎます。他のベンダーとは異なり、イルミオの可視性と適用はコンテナだけでなくハイブリッド攻撃対象領域全体に及ぶため、SecOpsチームはポリシーサイロを排除し、既存の運用をコンテナに拡張してサイバーレジリエンスを向上させることができます。

基礎となるノード間では、 また、Illumioは通信を強制し、未知の悪意のあるコードがKubernetesクラスターからノードに逃げた場合、その悪意のあるコードが隣接するノードに伝播するのを防ぎます。これは、Illumioがこれらのノード間でセッションが確立されるのを防ぐために可能です。イルミオは、ソフトウェアサプライチェーンの初期に導入された脅威であっても、侵害は避けられないと想定しているため、Kubernetesクラスターは、基盤となるインフラストラクチャを破壊することを意図したランサムウェアから保護されています。
IllumioでKubernetesのセキュリティをシフトレフトする方法
サイバーセキュリティでは、シフトレフトとは、コード開発ライフサイクルの開始時にセキュリティソリューションを導入することを指します。
- ライフサイクルの 右側 は、コードをアプリケーションとしてホストし、その前にファイアウォールをデプロイすることを表します。
- 左側は、開発中のコードの誕生を表しています。
マネージドワークロードに、後で起動して隣接するホストに拡散しようとするコードに埋め込まれた未知の脅威が含まれている場合、イルミオはその脅威の拡散を防ぎます。
これは、イルミオがその脅威の意図を知らなくても当てはまります。ほとんどの検出と対応のセキュリティソリューションは、決定を下す前に脅威の性質を理解しようとします。しかし、イルミオは決定を下す前にこれを理解しようと時間を無駄にしません。ほとんどのワークロードに必要な横方向通信の量は限られており、ほとんどの開いているポートは閉じるか、継続的に監視する必要があります。デバイスは隔離でき、イルミオはどのような種類の損傷が試みられているかを知ることなく、すべての横方向通信を防ぐことができます。
Kubernetesはランサムウェアの影響を受けないと見なすべきではありません。予防は修復の最良の形式であり、イルミオは、Kubernetesであっても、ランサムウェアがすべてのワークロードに感染するのを防ぎます。
イルミオがランサムウェアの拡散からKubernetesを保護する方法について詳しく知りたいですか?無料相談とデモについては、今すぐお問い合わせください。