コンテナセキュリティの基礎知識【後編】
「コンテナ」「オーケストレーター」のセキュリティを脅かす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
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？ 不足する対策を16項目でチェック -
製品資料
[株式会社ウェーブスプリッタ・ジャパン] 100Gbps対応の光トランシーバーはどう選ぶ？ 10分で分かる選定のポイント -
製品資料
[株式会社フィックスターズ] 組み込み開発の生産性と機密性を両立、自社環境で構築する「セキュアAI」活用術 -
製品レビュー
[ServiceNow Japan合同会社] 問い合わせの約9割を自動で解決、AI主導の自律型CRMがもたらす業務変革の全貌 -
市場調査・トレンド
[ServiceNow Japan合同会社] AI活用が業務自動化で止まる理由は何か？ 調査で判明した課題と変革への道筋
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
マンガで解説：採択率は3割台？ デジタル化・AI導入補助金申請の落とし穴
-
2
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
3
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
4
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは？
-
5
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
6
Anthropicが明かす AIは入力データを「どこまで覚えているのか」
-
7
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
8
GitHubが指摘 AIが書いた「おそらく動くコード」が招くシステム崩壊
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
「高すぎるGPU」を捨てAI推論をCPUへ Armが示す電力とコストの現実解
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
6
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド：25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
10
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー