コンテナセキュリティの基礎知識【後編】
「コンテナ」「オーケストレーター」のセキュリティを脅かす4大脆弱性
コンテナとオーケストレーターを安全に運用する上で、対処すべき代表的な4種類の脆弱性がある。それらの概要と、脅威を軽減する手段を紹介する。
前編「いまさら聞けない『コンテナ』『オーケストレーター』の仕組みと役割」では、アプリケーションの稼働環境を仮想化する「コンテナ」と、その管理やデプロイ(配備)を効率化する「コンテナオーケストレーター」(「コンテナオーケストレーションツール」とも。以下、オーケストレーター)の基礎知識を紹介した。後編では、コンテナやオーケストレーターに関わるセキュリティリスクと、その対策について説明する。
コンテナやオーケストレーターの代表的な脆弱性
コンテナとオーケストレーターの脆弱(ぜいじゃく)性の大半は、サイバーセキュリティ専門家にとってなじみがあるだろう。というのも、これらの脆弱性はOSとアプリケーションが持つ典型的な脆弱性だからだ。具体的には、次の4種類がある。
- アクセスと承認の脆弱性
- APIサーバへのアクセスの脆弱性
- コンテナイメージの脆弱性
- コンテナ間のトラフィックの脆弱性
これら4つの脆弱性について紹介しよう。
脆弱性1.アクセスと承認の脆弱性
前編で紹介したTesla Motorsと電子商取引構築サービスを手掛けるShopifyの事例では、どちらもアクセスと承認に原因があることは注目に値する。Teslaのケースでは、システム構成に不備があり、オーケストレーター「Kubernetes」のセキュリティを確保できていなかった。その結果、Kubernetesを経由してシステムが侵害を受けた。Shopifyのケースでは、攻撃者はAPI(アプリケーションプログラミングインタフェース)サーバに不正アクセスし、コンテナクラスタを操作できる脆弱性が見つかった。
どのアプリケーションとOSについてもいえることだが、開発者は全てのアクセス・承認の構成とセキュリティ確保に細心の注意を払わなければならない。そのためには、アクセスをロックダウン(制限)し、修正プログラムを適用してシステムを最新状態に保つ必要がある。
脆弱性2.APIサーバへのアクセスの脆弱性
APIサーバはオーケストレーターを操作するためのフロントエンドだ。APIサーバを「正しい資格情報を持つアプリケーションのみに通行を許可した正面玄関」だと考えてみてほしい。偽の資格情報やなりすましによって攻撃者がこの正面玄関を突破すると、コンテナが不正アクセスにさらされることになる。APIサーバを保護するためには、全てのアクセスと承認を扱う領域を用意することが不可欠だ。
脆弱性3.コンテナイメージの脆弱性
コンテナイメージはオーケストレーターの“DNA”、コンテナを作成するための処方箋のようなものだ。巧妙なハッカーは、コンテナイメージにマルウェアを仕込んで、危害を及ぼし得る“毒入りコンテナ”を生成する。さらに巧妙なハッカーであれば、オーケストレーターの状態監視コンポーネントを制御し、毒入りコンテナが検出されないようにすることも可能だろう。保有する全コンテナイメージを蓄積した「イメージレジストリ」も侵害の対象になり得る。その目的は、マルウェアを仕込んだコンテナイメージの存在を隠すことだ。従ってコンテナイメージの変更を検出できることや、変更あるいはコンテナ自体を管理できることも同様に重要になる。
脆弱性4.コンテナ間のトラフィックの脆弱性
コンテナは基本的に自己完結型である一方、コンテナ同士は相互に通信する。通信には暗号化した経路を使用する。ただし暗号化は、もろ刃の剣になり得る。暗号化によって、正当なデータフローだけでなく、マルウェアの転送も隠れてしまうためだ。あるコンテナが侵害されると、他のコンテナがマルウェアに感染する恐れがある。
コンテナにまつわるその他の脆弱性を理解する資料としては、米国立標準技術研究所(NIST)のガイドライン「NIST Special Publication 800-190」(SP 800-190)がお薦めだ。ただし前述の通り、ここで挙げた脆弱性は、多くの専門家が学んだ標準的な脆弱性のバリエーションにすぎない。目新しいのは「コンテナとオーケストレーターという新しい概念に関係している」点だけだ。
コンテナセキュリティのベストプラクティス
サイバーセキュリティ専門家が取り組むべきことは2つある。
1つ目は、開発者と膝を突き合わせて、ソフトウェアの開発サイクル全体でコンテナとオーケストレーターのセキュリティ状態を確認することだ。このサイクルは計画と分析、開発、導入、運用中の管理(廃棄を含む)といった要素で構成される。本稿で取り上げた脆弱性については特に留意してほしい。
リスクの保護と軽減の計画についてチームで話し合うことも重要になる。Shopifyのように、バグ(欠陥)を発見した人に報酬を与える「バグ報奨金プログラム」に投資するのもよいだろう。Shopifyは、バグ報奨金プログラムに100万ドル以上を費やしてきたという。
2つ目は、コンテナとオーケストレーターのセキュリティ確保に重点を置いたツールへの投資を検討することだ。そのようなツールを提供するベンダーには以下がある。
- Aqua Security Software
- Capsule8
- Layered Insight
- NeuVector
- StackRox
- Tenable Network Security
- Tigera
- Twistlock
コンテナとオーケストレーターは、開発部門に大きな価値をもたらす一方で、セキュリティのリスクももたらす。最善のアプローチは、脆弱性の特定とリスク軽減の両方について積極的に取り組むことだ。自社を保護できる技術とプロセスの予算を確保して導入してほしい。
Copyright © ITmedia, Inc. All Rights Reserved.
コンテナセキュリティの基礎知識
コンテナの企業利用が広まるにつれ、それらを狙ったサイバー攻撃のリスクも高まる。あらためてコンテナとそれを操作するオーケストレーターについて理解し、保護のベストプラクティスを学ぶ。
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー