実はリスクが多いコンテナのセキュリティを確保する方法コンテナはセキュリティホールまみれ?

リポジトリで公開されているコンテナの多くには多数の脆弱性が含まれており、さらに改ざんされるリスクもある。コンテナからコンテナへ、リスクが水平移動する恐れもある。これらにどう対処すればいいのか。

2019年11月21日 08時00分 公開
[Aaron TanComputer Weekly]

 コンテナにはさまざまなメリットがある。だが、それに伴ってアーキテクチャやプラクティスに変化が起き、新たな課題やチャンスも生まれる。

 これまでのセキュリティモデルは、複数階層のセキュリティ製品を使うことでITシステムの課題に対処してきた。これによってアジャイル開発の天敵となるストレスや低速なプロセスが生み出されていた。だが新しいアプローチは結果を重視し、テクノロジーツールやプラクティスを活用してセキュリティを確保する。

 継続的デリバリー(CD)において、セキュリティの鍵となるのが自動化だ。開発者はコンテナを使うことで、顧客のニーズに集中してコードを素早く作成できる。だが、広く使われているコンテナイメージとパブリックコンテナリポジトリがサプライチェーン攻撃を受けた場合、自動化とコンテナインフラの規模によっては被害が悪化する恐れがある。

Docker Hubのハッキング

 2019年4月、世界最大のコンテナイメージのライブラリとコミュニティーである「Docker Hub」がハッキングを受け、約19万人(Dockerの顧客ベースの5%)のユーザー名、ハッシュ化されたパスワード、GitHubとBitbucketのアクセストークンが漏えいした。

 さらに、Kenna Securityが2019年に実施した調査によって、Docker Hubのコンテナイメージトップ1000の多くに何らかの脆弱(ぜいじゃく)性が含まれていることが分かった。

 最も古いコンテナは150万回利用されており、未解決の脆弱性は431件以上に上るという。約170万回利用されたkeyvanfatehi/sinopiaコンテナには総計2000件以上の脆弱性が見つかっている。

 だが脅威検出と脆弱性へのパッチ適用は、コンテナセキュリティの側面のほんの一部にすぎない。この件に関してはRed Hatが「コンテナ・セキュリティの10大要素」として詳しく解説している。

コンテナの全体的なセキュリティ確保

 Red Hatのアジア太平洋部門でアプリケーションプラットフォーム製品の地域製品管理ディレクターを務めるビシャール・ガリワラ氏によると、コンテナのセキュリティを全体的に確保するには、これらの層(ホストOS、ネットワーク、ストレージ、コンテナ化アプリケーションにアクセスを付与するAPI)が必要になるという。

 Red Hatのモデル中で最も重要なのがコンテナホスト(通常はLinuxサーバ)のセキュリティだと指摘するガリワラ氏は次のように話す。「コンテナホストに脆弱性があれば、コンテナ管理プラットフォーム全体が侵害される恐れがある」

 コンテナのセキュリティを確保するには、信頼性の高いソースとレジストリを使わなければならない。この点についてはPivotalのウォルター氏も強調している。「コンテナプラットフォームは、ビルド済みのイメージを運用環境にプッシュする前にレジストリに格納する。レジストリが侵害されると、運用環境に導入されるイメージを攻撃者が変更できる。そのため、レジストリを厳しく管理統制することが不可欠だ」

 Red Hatはコンテナカタログを用意し、さまざまなミドルウェア、データベース、言語ランタイムの認証済みコンテナイメージを一覧にしている。「例えばNode.jsに重大な脆弱性があれば、Red HatのNode.jsの全コンテナが新しいセキュリティ修正プログラムによって全て自動的に再構築される」(ガリワラ氏)

 レジストリに関しては、Red Hatは「OpenShift」のコンテナレジストリへのアクセスを統制する厳しい制御を構築している。開発者がイメージをビルドする際は、脆弱性スキャンなどの一連のポリシーやプロセスを適用しなければ、そのイメージは使用可能とは認定されない。

 CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインにまたがるビルドプロセスの管理も、セキュリティ脆弱性を調査するための鍵になるとガリワラ氏は語る。Synopsysの「Black Duck Hub」やJFrogの「Xray」などのスキャナーを使ってリアルタイムに既知の脆弱性を確認すれば、開発者はセキュリティホールを特定し、必要に応じてインフラ、ミドルウェア、アプリケーションレベルでコンテナイメージを再構築することが可能だ。

 コンテナの展開に際しては、クラスタ内に展開できるものを制御することが必要だ。「例えば、適切に記述されていないコードが原因でルートアクセスを求めるコンテナが導入されることがあるが、こうしたことを防ぐ必要がある」とガリワラ氏は言う。

不適切な分離

 コンテナオーケストレーションプラットフォームを適切に管理すれば、ホストやその他のコンテナのセキュリティリスクが軽減される。だが、名前空間とファイルシステムが不適切に分離されることが依然としてよくあるとPivotalのウォルター氏は指摘する。

 特権コンテナにも懸念がある。特権コンテナでは、コンテナの管理者がホストの実質的な権限を得ることができる。ウォルター氏は次のように語る。「同様に、共有フラットネットワークで全てのコンテナアプリケーションをホストすることにより、侵害されたアプリケーションから別のアプリケーションにリスクが水平移動するリスクが高まる」

 「セキュリティチームは、使用中のネットワーク層にトラフィックを制限して、アプリケーションが相互通信する際は宣言的なビジネスロジックが基盤になるようにする必要がある」

 また、企業がコンテナアプリケーションを展開するにつれ、API呼び出しを管理・認証するためのAPI管理が不可欠になる。トラフィックのスムーズな流れを維持するためであり、Webシングルサインオン(SSO)をサポートするためでもある。

 Red Hatのガリワラ氏によると、フェデレーション導入モデルでは、複数のパブリッククラウドとオンプレミスデータセンターでセキュリティとアクセス制御を同レベルに維持する役割を、承認機能や認証機能と共にAPI管理が担っているという。

 だが、コンテナとモノリシックアプリケーションは、近い将来まで共存し続けると予想される。現在ほとんどの企業がアプリケーションのポートフォリオをリファクタリングし、プラットフォームを切り替え、ホストを変更するためにアプリケーションの最新化戦略を立てている。

 コンテナアプリケーションとレガシーアプリケーションが点在する環境のセキュリティを管理する一般的なアプローチを「Two-Speed IT」(2速IT)という。耐用期間の長いサーバには従来のセキュリティポリシーと制御を使い、変化の少ない一時ワークロードに、より動的な方法、つまり継続的な監査と検査を使用するアプローチを指す。

 このアプローチは、各エコシステムで適切な手法を使うメリットを提供し、コンテナの動的な性質に対応するように構築されていない従来のポリシーのためにイノベーションが遅れるのを防ぐ。

 既存のモノリシックサーバを保護するのにコンテナの不変、動的、かつ一時的な性質が活用されないのはよくあることだが、それではもったいないとウォルター氏は語る。

 「ユーザーが使う重要な機能をマイクロサービスにリファクタリングすれば(しばしば侵害の原因となる)パッチ適用が難しいアプリケーションからユーザーの機器を保護することができる。このアプローチは、モノリシックなバックエンドアプリケーションを変更する必要性を減らすことで継続的な攻撃のリスクを軽減する。そして、不正アクティビティーの検出をしばしば妨害するノイズを減らす」(ウォルター氏)

Copyright © ITmedia, Inc. All Rights Reserved.

髫エ�ス�ス�ー鬨セ�ケ�つ€驛「譎擾スク蜴・�。驛「�ァ�ス�、驛「譎冗樟�ス�ス驛「譎「�ス�シ驛「譏懶スサ�」�ス�ス

製品資料 サイバーリーズン合同会社

“無防備な玄関”はすぐ狙われる 気付けていない「防御の穴」を可視化するには

クラウド利用やリモートワークが急速に広まる中、攻撃者にとって格好の的となる対象も増えている。しかし、増加する一方の攻撃対象面をIT部門やセキュリティ部門が常に把握し続けることは難しい。この状況をどうすれば打開できるのか?

製品資料 フォーティネットジャパン合同会社

クラウドに必要な「データドリブンなセキュリティ」を実現する方法とは?

クラウド利用が当たり前となった今日、セキュリティ対策もまたクラウド環境に適したものでなくてはならない。とはいえ、大量のデータポイントが生成されるクラウド領域にあって、その全てのポイントを網羅するのは並大抵のことではない。

製品資料 株式会社ウィザース

SaaS利用拡大に伴うアカウント分散問題、クラウド時代に求められる認証基盤とは

クラウドの利用拡大に伴い、SaaSアカウントの分散が課題となっている。一般的なシングルサインオンではカバーできないSAML非対応サービス、ポリシーに準拠しない私用デバイスでのログインなどのリスクには、どのような対策が有効なのか。

製品資料 ServiceNow Japan合同会社

脅威はランサムウェアだけではない、重大なセキュリティインシデントをどう防ぐ

ランサムウェア以外にもさまざまなサイバー攻撃が企業を襲い続けているが、重大なセキュリティインシデントへの対策を適切に行えている企業は今も少ない。その理由や、状況を改善するための4つのステップを詳しく解説する。

技術文書・技術解説 ServiceNow Japan合同会社

限られた人材でインシデントや脆弱性への対応を迅速化、その鍵となるのは?

セキュリティ対策チームの57%が人材不足の影響を受けているといわれる昨今、インシデントや脆弱性への対応の遅れが、多くの企業で問題視されている。その対策として有効なのが「自動化」だが、どのように採り入れればよいのだろうか。

アイティメディアからのお知らせ

From Informa TechTarget

なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか

なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか
メインフレームを支える人材の高齢化が進み、企業の基幹IT運用に大きなリスクが迫っている。一方で、メインフレームは再評価の時を迎えている。

繧「繧ッ繧サ繧ケ繝ゥ繝ウ繧ュ繝ウ繧ー

2025/08/29 UPDATE

  1. 縲�3譌・縺ァ繝代ャ繝√€阪〒縺ッ繧ゅ≧謇矩≦繧後€€蟶ク諷句喧縺吶k窶�48譎る俣莉・蜀�€昴�謾サ謦�
  2. Google縺梧€昴>謠上¥AI鬧�虚縲後お繝シ繧ク繧ァ繝ウ繝亥梛SOC縲阪�窶懊い繝ゥ繝シ繝育夢繧娯€昴r縺ェ縺上○繧九°
  3. 縲瑚コォ莉」驥代r謾ッ謇輔≧縲堺サ・螟悶�繝ゥ繝ウ繧オ繝�繧ヲ繧ァ繧「蟇セ遲悶�譛ャ蠖薙↓縺ゅk縺ョ縺具シ�
  4. 縺ェ縺懊€後さ繝シ繝臥函謌植I縲阪r菫。縺倥※縺ッ縺�¢縺ェ縺�シ溘€€萓ソ蛻ゥ縺輔↓貎懊�窶�5縺、縺ョ繝ェ繧ケ繧ッ窶�
  5. 窶懷�縺ヲ縺ョ證怜捷縺檎�エ繧峨l繧区律窶昴↓蛯吶∴繧九€訓QC縲咲ァサ陦後�譬ケ豺ア縺�囿螢√→縺ッ��
  6. 窶�224荳�ココ豬∝�窶昴�陦晄茶縲€邀ウ繧ケ繝シ繝代�繧定・イ縺」縺溘€後Λ繝ウ繧オ繝�繧ヲ繧ァ繧「縲阪�豺ア蛻サ縺ェ迴セ螳�
  7. 縲後ぞ繝ュ繝医Λ繧ケ繝育ァサ陦後€阪�縺ゥ縺薙°繧臥捩謇九☆縺ケ縺搾シ溘€€SASE繧剃スソ縺」縺滉コ倶セ�5驕ク
  8. AI縺ォ縺ッAI縺ァ蟇セ謚励○繧遺€補€墓立譚・繧サ繧ュ繝・繝ェ繝�ぅ縺娯€懈�ケ譛ャ窶昴°繧牙、峨o繧�3縺、縺ョ譁ー謌ヲ逡・
  9. 蛹サ逋よゥ滄未縺後€後そ繧ュ繝・繝ェ繝�ぅ隧穂セ。88轤ケ縲阪↓螳牙ソ�〒縺阪↑縺�ィウ縲€蠢�ヲ√↑繧オ繧、繝舌�蟇セ遲悶���
  10. Google Cloud縺ョ螟ァ隕乗ィ。髫懷ョウ縺ァ豬ョ縺榊スォ繧翫↓縺ェ縺」縺溘€碁國繧後◆蜊倅ク€髫懷ョウ轤ケ縲阪→縺ッ��

ITmedia マーケティング新着記事

news017.png

「サイト内検索」&「ライブチャット」売れ筋TOP5(2025年5月)
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。

news027.png

「ECプラットフォーム」売れ筋TOP10(2025年5月)
今週は、ECプラットフォーム製品(ECサイト構築ツール)の国内売れ筋TOP10を紹介します。

news023.png

「パーソナライゼーション」&「A/Bテスト」ツール売れ筋TOP5(2025年5月)
今週は、パーソナライゼーション製品と「A/Bテスト」ツールの国内売れ筋各TOP5を紹介し...