コンテナセキュリティの基礎知識【後編】
「コンテナ」「オーケストレーター」のセキュリティを脅かす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
-
製品資料
[ファインディ株式会社] AI利用率だけでは説明できない成果 開発組織の競争力を生む「開発資本」とは? -
製品資料
[ニュータニックス・ジャパン合同会社] AI活用を成功へ導く、シンプルで費用対効果に優れたクラウド基盤とは? -
製品資料
[ニュータニックス・ジャパン合同会社] マネージドKubernetesには限界も――メリットをフル活用する新たな選択肢とは? -
技術文書・技術解説
[ニュータニックス・ジャパン合同会社] 決断の日が迫る「vSphere 8」サポート終了問題 考慮すべきリスクと選択肢は? -
製品資料
[サイバーソリューションズ株式会社] メール誤送信対策のルールが肥大化 苦しむ情シスはどうすれば救われるのか?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
3
「アップグレードできないJava」をどう守る IBMとRed HatがAIで400件超修正
-
4
パッチなしで「今すぐサーバを落とせ」 Kiteworks異例警告の波紋
-
5
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
6
Copilot導入で陥る“目的化”の落とし穴 定着の鍵は「作り込まない」こと
-
7
MS&ADグループの目指す「AX」の全貌 本山CDOが語る変革の本質
-
8
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
9
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
10
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
2
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
3
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは?
-
8
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
9
「IT史に名を残すシステム障害」8選
-
10
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー