
公開日
2022年11月13日
スッキリ、繋げて、コンテナセキュリティを得意分野に! #3 コンテナのマルウェア対策の考え方
このシリーズでは、コンテナセキュリティの重要だけど分かりづらいと思われる部分を中心に扱います。
お忙しい皆さんに代わって、あちこちから情報をかき集めて整理していきます。(おそらく皆さんにとっては時短になるはず!)
皆さんの、ここが分からなかった!というモヤモヤをスッキリさせ、点と点を繋げていき、コンテナ分野を『苦手』から『面白い≒得意』にできるようなコンテンツをお届けしていきます。
(面白いと感じられれば、積極的に学習が進む好循環が回って得意になるという寸法)
本シリーズのおすすめの読み方は、根幹となる『コンテナセキュリティで重要な観点』(初回投稿)をおさえて、枝葉(今回以降)のうち、皆さんの気になるものをご確認いただければと思います。
今回は、セキュリティ対策の基本であるマルウェア対策について見ていきます。
コンテナにおいては、従来とは異なるマルウェア対策のアプローチを取ることになります。
実は色々な対策があり、個別で見るとバラバラな感じがするので、今回まとめて整理してみました。
従来のマルウェア対策といえば、サーバに対策ソフトを導入するイメージですが、コンテナではそもそも、従来のマルウェア対策ソフトを導入できないケースがあります。
また、コンテナイメージという要素やコンテナ自体の生存期間が短い点なども影響して、異なるアプローチを取る必要がある、あるいは取ったほうが良い、ということを心掛けください。
従来と異なる点や対策方法について、関連する技術や用語に触れながら詳しく解説していきます。
マルウェア混入タイミングと感染経路
マルウェアとは、悪意のあるソフトウェアや悪質なコードの総称で、ウイルス、ワーム、トロイの木馬などいくつかの種類があります。
ランサムウェアもそのひとつですが、コンテナ環境では、感染させた環境で不正に仮想通貨のマイニングを行うタイプのものが流行していました。
マルウェアは、実行ファイルを何等かのトリガーで起動することで実行されて、悪意のある行動が行われます。
このブログでは、ファイル実体を持たないファイルレスマルウェアの話も扱いますが、まずは従来型のファイル実体のあるマルウェアについて話をしていきます。
マルウェアの実行ファイルは、何等かの経路を辿って環境の中に混入します。
コンテナにおいて、マルウェアの混入タイミングと感染経路は次のようなことが考えられます。
①(デプロイ前)コンテナイメージにはじめから混入しているケース
感染経路:ベースイメージに混入、コンテナビルド(作成)時にビルド環境が侵害されて混入、使用するOSSやローカルファイルに紛れて混入など
②(デプロイ時)コンテナのデプロイ時に混入するケース
感染経路:DockerfileのENTRYPOINTで実行するスクリプトにマルウェアをダウンロードする命令が書かれているケースなど
(↑ コンテナイメージにマルウェア自体を含まず、コンテナ実行時に動作する挙動を悪用したケース)
③(デプロイ後)稼働中のコンテナのファイルシステム等に混入するケース
感染経路:脆弱性を突いて侵害後にダウンロードさせられるケース、アプリケーションのファイルアップロードで不正ファイル混入、悪意ある者にコンテナ操作をされる、コンテナに直接乗り込まれてファイルを置かれるケースなど
また、マルウェア混入タイミングや感染経路を考える上では、以下のように、コンテナを構成する各コンポーネントを思い浮かべるとよいでしょう。

そして、混入タイミングに違いがあるにせよ、共通していることとして、実際にマルウェアが活動をするのは稼働中のコンテナ環境であることです。
コンテナイメージ内に混入していても、コンテナとして動作しない限りはマルウェアも動き出さないということです。
上記のようなことを踏まえつつ、次にマルウェアの対策について見ていきましょう。
対策の種類と対策例の一覧
マルウェアの対策として直接的な対策と間接的な対策で分けてみます。
直接的な対策は、従来のマルウェア対策ソフトのように、マルウェアを検出して駆除するようなものとします。
一方、間接的な対策は、マルウェアそのものを検出するのではなく、マルウェアを配置・実行できなくしたり、マルウェア感染後の不審な挙動や最終目的の阻止をしたり、といった形で対策するようなものとします。
それぞれの対策で何ができるか、という点が大事になってきます。
例えば、マルウェアの検出はできるが駆除まではできない、異常を検知するがブロックはできない、従来の実行ファイル型のマルウェアはブロックできるがファイルレスマルウェアのブロックはできない、など。
また、別の観点では、対策を実施する場所やタイミングなども、対策によって異なります。
マルウェアが混入するタイミングとも関係しますが、コンテナイメージを事前にスキャンするなど、DevOpsの早い段階(シフトレフト)での対策も含まれます。

さらに、今回紹介するものの中には、ユーザの作り込みによる対策も多く含まれています。
コンテナにおいては、ユーザによるセキュリティの作り込みも重要な要素になっています。
興味深いことに、デプロイ後のコンテナを保護する対策も、対策自体を実装するタイミングは、設計段階やDevOpsの早い段階、デプロイ前の作り込みによるものがあるということです。
コンテナにおいては、シフトレフトでのセキュリティ実装が可能であり、そうすることで、リスクの早期発見、修正コストを最小限に抑えることなどにも繋がります。
感染タイミングや感染経路を鑑みると、マルウェア対策として重要なポイントは、デプロイ前で出来る限り対策しつつ、デプロイ後に混入するマルウェアのケアも大切という点です。
さて、ここで対策例の一覧を列挙します。このあとの章でそれぞれ詳細に触れることとします。

直接的な対策の例:
①コンテナイメージに対する静的スキャン
②コンテナイメージに対する動的スキャン
③稼働中のコンテナに対するリアルタイムスキャン
④その他ボリューム・ストレージに対するスキャン
間接的な対策の例:
①素性の知れないものをベースイメージや構成に含めない
②Distrolessの活用やマルチステージビルドで余計なものをイメージに含めない
③コンテナイメージの脆弱性スキャンを実施する
④ビルド環境をセキュアにする
⑤スキャン済イメージや信頼するイメージのみを利用することを確実にする
⑥Docker APIの公開設定の無効化やクラウドアカウントやオーケストレータ、ホストのアクセス制御
⑦コンテナをRead Onlyで動作
⑧稼働中コンテナの正規挙動以外を検出
⑨稼働中コンテナの不審な動作を検出
⑩コンテナの通信先を制限
⑪イメージに存在しないファイル実行の防止
⑫稼働中のコンテナに対する脆弱性を突いた攻撃を検出・ブロックする
⑬ネットワーク上で不審な通信を検出
対策例の詳細解説(直接的な対策)
対策例として、マルウェアを検出する直接的な対策をそれぞれ見てみます。

①コンテナイメージに対する静的スキャン
対象: | コンテナイメージ内に潜伏するマルウェア |
概要: | コンテナイメージの各レイヤに存在するファイルをパターンファイルと突き合わせる等してマルウェアか判別 |
タイミング: | デプロイ前の任意のタイミング |
メリット: | ベースイメージやイメージ内に格納されているファイルを事前にチェックし、デプロイ前にリスクを把握、対処が可能な点 |
留意点: | ファイルレスマルウェアや実際の挙動を見ての判別でない、また、あくまでもコンテナイメージ内に格納されているファイルが対象 |
方法: | 3rd Party製品等によるコンテナイメージスキャンなど |
②コンテナイメージに対する動的スキャン
対象: | コンテナイメージ内に潜伏するマルウェアやデプロイ時に挙動を開始するマルウェア |
概要: | コンテナイメージをサンドボックス環境や検証環境で実際に動作させてその挙動に不審なものがないか判別 |
タイミング: | デプロイ前の任意のタイミング |
メリット: | 静的スキャンでは発見できない実際の挙動を見てのマルウェア検出や、コンテナデプロイ時にダウンロードされるように仕込まれた(ENTRYPOINTで指定したスクリプト等)ものを、本番環境デプロイ前に発見し、対処が可能な点 |
留意点: | ファイルレスマルウェアの検出をするためにはメモリ上のイベント監視の仕組みや、不審な挙動を捉えるなどの技術が必要 |
方法: | 3rd Party製品等による解析ツールや解析サービス、事前検証による動作確認など |
③稼働中のコンテナに対するリアルタイムスキャン
対象: | 稼働中コンテナのファイルシステム内に配置されるマルウェア、実行されようとしたマルウェア |
概要: | 稼働中コンテナの読み書きされるファイルをパターンファイルと突き合わせる等してリアルタイムにマルウェアか判別 |
タイミング: | 稼働中コンテナのファイルシステムに対象のファイルが読み書き(実行)されるとき |
メリット: | 稼働中コンテナに対してマルウェアの混入や実行を検出、場合によっては駆除も可能 |
留意点: | 対策製品の導入形態を要確認(ものによっては要件に合わないケースも想定される)、ファイルレスマルウェアの検出には別技術での対策が必要 |
方法: | 3rd Party製品等をコンテナ内、サイドカー、コンテナホスト上、特権コンテナのような形で導入 |
④その他ボリューム・ストレージに対するスキャン
対象: | 稼働中コンテナが参照するボリューム・ストレージ内に潜伏するマルウェア |
概要: | ボリュームやストレージに書き込まれるファイルや読み出されるファイルをパターンファイルと突き合わせる等してマルウェアか判別 |
タイミング: | ボリュームやストレージ内のファイルをリアルタイムまたは定期的に確認 |
メリット: | 稼働中コンテナのファイルシステム内でなくボリュームやストレージを活用する場合のマルウェア対策が可能 |
留意点: | コンテナでなくボリュームやストレージ側で対策が必要なケースが多く、リアルタイム性を求められる場合は特に要件にマッチするか確認する必要がある |
方法: | ボリュームやストレージのファイルをスキャンする3rd Party製品等を導入 |
対策例の詳細解説(間接的な対策)
続いて、マルウェア検出でない間接的な対策について見ていきます。
間接的な対策では特に、ユーザの作り込みに依存するものやコンテナ技術と関連する部分が多いため、周辺技術とともに見ていくことになります。

①素性の知れないものをベースイメージや構成に含めない
対象: | コンテナイメージ内に潜伏するマルウェアやデプロイ時に挙動を開始するマルウェア |
概要: | 非公式のコンテナイメージや素性の知れないOSSのツールなどをコンテナの構成要素に含めない、または注意して組み込むようにすることで、マルウェア混入のリスクを抑える |
タイミング: | コンテナイメージとしてビルドする前、設計段階 |
メリット: | 素性の知れないものを加えないようにすることはマルウェア以外のリスクにも同時に対処可能 |
留意点: | 素性の知れないものだけが危険ではないことを念頭に、コンテナイメージのスキャンを通してマルウェアが混入していないかを確認すると良い |
方法: | ユーザの作り込み |
②Distrolessの活用やマルチステージビルドで余計なものをイメージに含めない
対象: | コンテナイメージ内に潜伏するマルウェアやデプロイ時に挙動を開始するマルウェア |
概要: | Distrolessなイメージの活用やマルチステージビルドを利用し、コンテナイメージ内に不要なファイルをイメージに含めないようにすることで、マルウェア混入のリスクを抑える |
タイミング: | コンテナイメージとしてビルドする前、設計段階 |
メリット: | 不要なファイルを含めないことでマルウェア混入リスクの低減の他、イメージの軽量化やチェックするファイル数を少なくできる |
留意点: | 必要と判断された領域内に潜伏している可能性やビルド時または後に悪意のある者にイメージ改変されるなどして、このようなイメージにもマルウェアが混入する可能性がある点に留意 |
方法: | ユーザの作り込み |
<関連用語>
Distroless:Linuxディストリビューション(ディストロ)で備えているシェルやパッケージマネージャなど、アプリケーション実行のみに不要なものを除いた、軽量なイメージ。
脆弱性を考慮する対象を減らす効果やマルウェア感染後などの挙動の制限などが期待できる。
マルチステージビルド:ビルド時に必要なものと最終的なコンテナ実行時(成果物)に必要なものが違うことに着目し、ビルド時のみ必要だったパッケージ管理ツールや中間ファイルを排除した、最小限のバイナリファイルと依存関係のみを含んだ軽量なイメージを作成するビルド手法。
③コンテナイメージの脆弱性スキャンを実施する
対象: | コンテナイメージに内在するマルウェア感染経路となりうる脆弱性 |
概要: | コンテナイメージに含まれるOSやアプリケーションに内在する脆弱性を検出 |
タイミング: | デプロイ前の任意のタイミング |
メリット: | ファイルレスマルウェアを含むマルウェア感染経路を、本番環境デプロイ前に発見し、対処が可能な点 |
留意点: | 脆弱性は日々発見されるため、定期的に最新の脆弱性情報をもとにチェックする必要がある |
方法: | 3rd Party製品等によるコンテナイメージスキャンなど |
④ビルド環境をセキュアにする
対象: | コンテナイメージ内に潜伏するマルウェアやデプロイ時に挙動を開始するマルウェア |
概要: | ビルド環境をセキュアにすることで、ビルド環境を侵害されてコンテナイメージを不正に操作し、悪意のある者による既存コンテナイメージへの改変(マルウェア混入など)をされるリスクを抑える |
タイミング: | デプロイ前(常時) |
メリット: | 他をセキュアにしてもビルド環境を侵害されることで破綻する可能性があるため、考慮が必須 |
留意点: | ビルド環境が自身の管理下にない場合もあるが、その場合も状況を把握しておく等が必要となる |
方法: | ビルド環境のサーバなどへの3rd Party製品等の導入、ビルド環境へのアクセス制御やユーザ権限の最小化など |
⑤スキャン済イメージや信頼するイメージのみを利用することを確実にする
対象: | コンテナイメージ内に潜伏するマルウェアやデプロイ時に挙動を開始するマルウェア |
概要: | 稼働環境にデプロイされるタイミングで、スキャン済イメージや信頼するイメージであるかどうかを署名などを通して確認 |
タイミング: | コンテナイメージを本番環境等にデプロイする際 |
メリット: | 稼働環境に安全が定かでないコンテナや身元不明のコンテナがデプロイされることを検出、場合によっては防止できる |
留意点: | 署名⇒検証であれば署名時の環境が侵害されていないか、スキャン済イメージであればスキャン時からデプロイまでの間に新たに発見・追加されたパターンに合致するものがないか、といった残存リスクを検討する |
方法: | 3rd Party製品などのイメージスキャンと連動してデプロイを制御するものの導入、コンテナを署名⇒検証する仕組みの導入 |
⑥Docker APIの公開設定の無効化やクラウドアカウントやオーケストレータ、ホストのアクセス制御
対象: | 稼働中コンテナへのマルウェア混入や稼働環境へのマルウェアを含むコンテナのデプロイなど |
概要: | Docker APIが誤って外部公開の設定になっていないかの確認や、各コンポーネントにおける認証情報の取り扱いやアクセス制御を強化することで、悪意ある者に環境を侵害されてコンテナ操作されるリスクを抑える |
タイミング: | 常時 |
メリット: | コンテナ自体をセキュアにしても、周辺環境がセキュアでないと破綻してしまう恐れがあるため必須の対策 |
留意点: | 設定ミスや意識の問題など、対策として人的要素が強いため、後からトレースできる仕組みを併用するなどが必要 |
方法: | ユーザの作り込み、認証情報の取り扱いのルール化、アクセス制御の強化 |
⑦コンテナをRead Onlyで動作
対象: | 稼働中コンテナのファイルシステムに新たに配置されようとするマルウェア |
概要: | コンテナのファイルシステムをRead Onlyモードで運用することで外部からのマルウェア混入を防止する |
タイミング: | 稼働中のコンテナへの対策 |
メリット: | 稼働中コンテナのファイルシステムへの書き込みを禁止することでマルウェアの配置やマルウェアの挙動を制限できる |
留意点: | Read Onlyモードを実現するために、システムの設計を考慮する必要がある。また、Read Onlyにおいてもファイルレスマルウェアのリスクは残存することに留意 |
方法: | 事前にRead Onlyにできるコンテナ設計をして、稼働させるコンテナをRead Onlyモードで稼働させる |
<関連用語>
Read Only:コンテナのファイルシステムを読み取り専用で動作させる。
これにより、悪意のある者によってファイルシステムに不正な書き込みがされることを防止。
コンテナでは不変性を維持することを良しとするため(イミュータブル)、永続的なデータはコンテナ外に保持することが望まれ、コンテナファイルシステム自体には基本的に書き込みしない。
⑧稼働中コンテナの正規挙動以外を検出
対象: | 稼働中のコンテナで実行されたマルウェア |
概要: | 稼働するコンテナの正規の挙動や許可する行動を事前定義しておき、それを逸脱した行為を検出。本来想定していない、マルウェア感染後の不審な動作を検出 |
タイミング: | 稼働中のコンテナでマルウェアが実行された後 |
メリット: | 未知のマルウェアに対してもその挙動の制限が可能、許可する動作のみを事前定義するため、作り込み後は堅牢になる |
留意点: | 正規の挙動や許可する行動について、事前にきちんと把握して正しく定義しておく必要がある |
方法: | 3rd Party製品等による正規な挙動を逸脱したものの検出 |
※正規挙動として登録しておくものの例:使用するシステムコールや起動プロセス、通信先など
⑨稼働中コンテナの不審な動作を検出
対象: | 稼働中のコンテナで実行されたマルウェア |
概要: | 稼働中コンテナの挙動を、挙動監視や行動ログの中から不審な挙動のルールと突き合わせて検出 |
タイミング: | 稼働中のコンテナでマルウェアが実行された後 |
メリット: | 未知のマルウェアに対してもその挙動の制限が可能、正規挙動の事前定義と比べて導入が簡単 |
留意点: | 不審な挙動がルールベースであるため、ルールにない不審な挙動のすり抜けのリスクは残存する |
方法: | 3rd Party製品等による不審な挙動の検出 |
※不審な挙動って?:マルウェア感染や侵害行為の各フェイズごとに行われる攻撃と思われる挙動(MITRE&ATTCK等も参照のこと)
⑩コンテナの通信先を制限
対象: | 稼働中のコンテナに配置されようとするマルウェアや実行されたマルウェア |
概要: | コンテナ間やコンテナ外部との通信を制限することで、マルウェア配置やマルウェア感染後の不正な通信を制限 |
タイミング: | コンテナ稼働中 |
メリット: | 未知のマルウェアに対しても挙動の制限や拡散の防止、出口対策が可能 |
留意点: | 正規の通信先からの経路での感染や拡散などのリスクは残存する |
方法: | コンテナオーケストレータやクラウド、3rd Partyのネットワークサービスや製品による通信制御 |
⑪イメージに存在しないファイル実行の防止
対象: | 稼働中のコンテナで実行されようとしたマルウェア |
概要: | 稼働中コンテナの元になっているコンテナイメージに含まれていないファイルの実行を防止することで、稼働後に混入したマルウェアの実行を防ぐことが可能 |
タイミング: | 稼働中のコンテナでマルウェアが実行されようとした際 |
メリット: | 未知のマルウェアに対しても対策が可能 |
留意点: | イメージ内に存在しないファイル実行が正規の挙動として存在する場合には、例外設定などを実施する必要あり。ファイルレスマルウェアに対しては別の対策を必要とする場合が多い |
方法: | 3rd Party製品等による対策 |
⑫稼働中のコンテナに対する脆弱性を突いた攻撃を検出・ブロックする
対象: | 稼働中のコンテナでマルウェア感染を試みる脆弱性を突いた攻撃を含む通信 |
概要: | コンテナで稼働するアプリケーションなどの脆弱性を突いた攻撃を含む通信を、ルールベースで突き合わせるなどして検出 |
タイミング: | 稼働中コンテナに対して不正な通信が行われた際 |
メリット: | ファイルレスマルウェアを含むマルウェア感染を防止できる可能性がある |
留意点: | 対策製品によってはコンテナ間の通信に対応していない等、通信を判定できる範囲を把握しておく必要がある |
方法: | ネットワーク上やコンテナホスト、コンテナ上などに導入する3rd Party製品等による対策 |
⑬ネットワーク上で不審な通信を検出
対象: | 稼働中のコンテナで実行されたマルウェア |
概要: | マルウェア感染後にC2サーバ等へ実施される不審な通信を検出、制御することで、感染後の被害拡大や最終目的を達成されるリスクを抑える |
タイミング: | 稼働中のコンテナでマルウェアが実行された後 |
メリット: | 出口対策として最終目的の達成を阻止できる可能性がある、コンテナ内でない箇所での多層的な対策となる |
留意点: | C2サーバ等の通信先をブロックリストで制御している場合には、未知の通信先を制御できないリスクが残存する |
方法: | ネットワーク上の通信を評価できる3rd Party製品等による対策 |
おまけ:ファイルレスマルウェアの対策
上記でも何度か出てきたファイルレスマルウェアについて、補足として説明していきます。
ファイルレスマルウェアは、ファイル実体を持たずにメモリ上で展開、悪意のある行為が実施されるマルウェアです。
これまで、Windowsのpowershellなどを隠れ蓑に、正規のプロセスに紛れて実行されてきました。
最近では、Linuxにおいてもファイルレスマルウェアが確認され、コンテナでも検出が見られています。
Linuxにおける主な流れは、脆弱性の悪用によりプロセスにインジェクションしてメモリ上にファイル作成⇒実行というものになります。
ファイル実体がないため、前までの章で紹介した対策例が有効打にならないことも多いです。
例えば、ファイル実体のあるマルウェア対策ではReadOnlyモードでの運用は非常に強力ですが、ファイルレスマルウェアは動作してしまうため、別の対策が求められます。
ファイルレスマルウェアの対策としては、以下のようなものが考えられます。
(上記の対策例の一部を含む)
対策例:
・ファイルレスマルウェア感染を実現可能な脆弱性をチェックするイメージスキャンの実施
・コンテナイメージにファイルレスマルウェアに感染させるような挙動が無いかをサンドボックス環境などで事前に確認
・メモリ上のファイルレスマルウェア感染に関連するイベント検知の仕組みの導入
・ファイルレスマルウェア感染経路としてのコンテナ間や外部との通信先の絞り込み
・ファイルレスマルウェア感染後の最終目的達成を阻止する出口対策としての不審な通信の検知・ブロック
まとめ
ここまでご覧いただき、ありがとうございます。いかがでしたでしょうか。
分量がだいぶ多くなってしまいましたが、全体感を捉えていただくためにひとつの記事として扱いました。
従来の対策としては単純なイメージのあるマルウェア対策ですが、コンテナにおいては多くの考慮ポイントがあったかと思います。
今回挙げているマルウェア対策はあくまでも例であり、特に間接的な対策についてはこの限りではないです。
列挙したすべての対策をするというよりも、どこを重点的にカバーするか、穴をどれだけ塞ぐことができるか等を意識して、多層防御でコンテナに対するマルウェア対策を検討いただければと思います。
重要なポイントは、デプロイ前で出来る限り対策しつつ、デプロイ後に混入するマルウェアのケアも大切という点です。
対策の具体的な方法については、今回の記事では扱っていないので、気になるものはWeb等でさらに調べてみてください。
また、これらの対策は対マルウェアだけでなく、他にもメリットをもたらすものとなります。
今後の記事においても上記で挙げた対策が再び登場することでしょう。
それぞれの対策について、他にどのようなメリットがあるか、ご自身でも考えを巡らせてみてくださいー!
コンテナにおけるマルウェア対策として、弊社Cloud Oneシリーズでは複数の製品で、こちらで扱った複数の対策を多層的に実施が可能です。
ぜひ、コンテナにおけるマルウェア対策として弊社Cloud Oneシリーズを検討いただければと思います。
本ブログシリーズでは、コンテナセキュリティについて、捉えづらい部分をスッキリ、理解の点と点を繋げて、全体像を捉えられるようにすることをテーマとしています。
皆さんがコンテナ分野を『苦手』から『面白い≒得意』にできるようなコンテンツをお届けしていきます!
※本ブログの内容はエンジニア個人の見解であり、弊社全体としての見解ではない点をご了承ください。
ブログシリーズ『スッキリ、繋げて、コンテナセキュリティを得意分野に!』
また、弊社ではコンテナ領域を含むクラウド向けセキュリティ対策製品群としてTrend Micro Cloud One™を提供しています。
30日間の無料トライアルもご用意しておりますので、以下も併せてご参照の上、ぜひ体験いただければと思います。

トレンドマイクロ株式会社
セキュリティエキスパート本部 セールスエンジニアリング部
サーバセキュリティチーム ソリューションアーキテクト
野村 達広