ついに Kubernetes がハッカーの標的に ― 絶対に負けられない戦いの幕開け

投稿日: 2021年10月19日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

要約

これまでは良いことづくめのKubernetes（K8s）にも、ついに魔の手が忍び寄ってきました。今年3月、K8sコンフィギュレーションの不備につけ込むコンテナ環境専門のマルウェア Siloscapeが見つかりましたが、これはK8sを狙った大々的なサイバー攻撃の序章にすぎないと見られています。オープンソースのK8sは急速な普及が進む反面、システム管理者の技術レベルに格差があり、今後さらにハッカーの格好の狙い目となることが危惧されています。

重要なのは適正なコンフィギュレーションを徹底することと、データ保護ソリューションを導入して確実なバックアップとリカバリのプロセスを適用すること。K8sが狙われているという報告は、実は悪い知らせではなく、対策を強化するうえで最も重要な「状況を把握すること」の第一歩です。Knowing is half the battle（敵を知れば半分勝ったようなもの）という格言もあるぐらいです。残りの半分は適切なデータ保護ソリューションに違いありません。

世界でもっともアジャイルな開発チームは？

残念ながら、この問いの答えはサイバー攻撃の犯罪グループだという説が有力です。

たとえば、米サイバーセキュリティ会社Check Point Softwareの調査によれば、週ごとのランサムウェア攻撃件数は今年6月で前年比93%増の1,210件に達しており、その躍進ぶり、というか増長ぶりは、世界のどのIT企業も凌いでいます。

そして、この犯罪グループの魔の手は、ついにKubernetesにも伸びてきました。

Kubernetesは、コンテナ環境を効率的に管理するオーケストレーション ツールのデファクトスタンダードとしての地位を確立し、これまでは良いことづくめで向かうところ敵なし状態でした。

しかし、今年3月、Siloscapeと呼ばれるマルウェアが確認され、Kubernetesコンフィギュレーションの不備につけ込んでコンテナ環境を専門に攻撃する世界初のマルウェアとして認知されました。

Siloscapeと命名された理由は、サイロ（隔離された部屋）つまりコンテナから抜け出して、クラスタ全体に攻撃を加えるからだそうで、一度クラスタ全体のデータを制御されてしまえば、ランサムウェア化するのも時間の問題と危惧されています。

つまり、いちばんの懸念はSiloscapeそのものよりも、SiloscapeがKubernetesの牙城に風穴を開けたという事実であり、このマルウェアがこれから始まる大々的な攻撃の最初の一矢にすぎないのではないか、という点です。

オープンソースのKubernetesは、誰でもすぐに使える便利さと急速な利用拡大のために、システム管理者の技術レベルに大きな格差が生じています。Kubernetesを採用した企業のうちの67％は誤ったコンフィギュレーションでKubernetesを使用しているという調査結果（Stackroxのレポート）もあります。まさにSiloscapeは、このような導入初期の不安定さにつけ込んだサイバー攻撃と言えます。

したがって、Kubernetesを狙ったサイバー攻撃に対する防御の第一歩は、適正なコンフィギュレーションを徹底することです。Kubernetesのドキュメンテーションは非常に丁寧に書かれてあり、クラスタの適切なコンフィギュレーションと管理の方法が詳しく説明されています。設定段階できちんとした手順を踏み、コンフィギュレーションを疎かにしないことが、Kubernetesセキュリティの基本となります。

しかし、それだけでは十分ではありません。Kubernetes環境はさまざまな要素で構成され、そのどこか1か所にでも脆弱性があれば、残りすべてのセキュリティが盤石でも意味がありません。つまり、個々のコンポーネントを常に最新バージョンにアップデートする必要があり、オープンソースのコンポーネントには特にこの作業が欠かせません。

これらは、要するにシステム管理者やオペレーターのセキュリティ意識を徹底することであり、最重要事項に違いないのですが、企業の重要データの命運をスタッフの心構えだけに任せるわけにはいきません。当然ながら、信頼できるデータ保護ソリューションを導入して、的確なバックアップとリカバリのプロセスをKubernetes導入と同時に施行する必要があります。

冒頭に書いたように、サイバー攻撃の犯罪グループは世界有数のアジャイルな開発チームであることを忘れないでください。犯罪グループは、常にこちらの一手先を読むので、システムそのものと同時にバックアップも狙ってきます。どんなに短いRTO（リカバリ時間目標）とRPO（リカバリポイント目標）を達成しても、バックアップ ファイルを攻撃されてしまっては元も子もありません。バックアップは誰も手出しをできないように、イミュータブルにしなければなりません。

しかも、Kubernetes環境のデータ保護ソリューションには、Kubernetes独自のアーキテクチャに対応したKubernetesネイティブなソリューションが必要です。プラットフォーム単位でデータを保護する従来型のセキュリティ ソリューションでは、Kubernetes環境に完全には対応しきれません。Kubernetes環境では、マイクロサービスで構成されるアプリケーションが複数ノードに分散され、動的にワークロードの再スケジュールを繰り返します。プラットフォーム単位ではなく、アプリケーション単位で、そのすべての構成を1つのまとまったユニットとして保護できるKasten K10のようなセキュリティ ソリューションが理想的です。

Kasten K10なら、ポリシーにもとづいて自動化されたバックアップ処理をクラウドネイティブ環境に適用でき、DevOpsのワークフロー全般に対するAPIサポートや、Amazon S3などのオブジェクト ストレージに対するWORM（write once read many）サポートを活用できます。

Kasten K10の最新バージョンV4.5の詳細については、前回のブログを参照してください。

今回のブログでは、ついにKubernetesがハッカー集団の標的にされ出したという悪いニュースについて解説しましたが、実のところ、これは必ずしも悪いニュースとは限りません。対策を強化するうえで最も重要なのは、「状況を把握すること」です。考えようによっては、Siloscapeは、これまでずっと無防備だったKubernetesクラスタに警鐘を鳴らしてくれているとも言えます。Knowing is half the battle（敵を知れば半分勝ったようなもの）という格言もあるぐらいです。重要なのは、これを機にしっかり対策を講じて、それを実践することです。

ところで、敵を知れば半分は勝ったも同然だとして、残りの半分は何でしょうか。ことKubernetesに関して言えば、残りの半分は適切なデータ保護ソリューションの導入に違いありません。

 

 

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。