セキュリティチェックシートやRFP（提案依頼書）に並ぶ「サーバーにアンチウイルスソフトを導入していること」という項目。コンテナ（アプリと依存関係をまとめて動かす軽量な実行単位）で本番環境を運用していると、この要件にどう答えればよいのか手が止まりがちです。ホストにアンチウイルスを常駐させる従来の発想が、コンテナではそのまま当てはまらないためです。
コンテナのマルウェア対策は、ビルド時・デプロイ時・実行時という3つのタイミングに分けて考えると整理できます。それぞれの段階で何を・どのツールで守るのかを押さえれば、自社の構成に当てはめて着手できます。
本記事では、コンテナのマルウェア対策を層ごとに解説します。イメージスキャンとランタイム検知の違いと使い分け、OSS・クラウド純正・SaaSそれぞれの代表的な手段、AWS・Azure・Kubernetes/ECS/Fargateといった環境別の当てはめまで扱います。開発・インフラ・DevSecOpsの担当者が、自社で何から入れるかを判断できる形で整理しました。
目次
一括ダウンロードする
なぜコンテナでは従来のウイルス対策（アンチウイルス常駐）がそのまま通用しないのか
はじめに、コンテナのマルウェア対策が従来のサーバー向けと分けて語られる理由を整理します。結論から言えば、ホストにアンチウイルスソフトを常駐させる方式が、コンテナでは成立しにくいか、そもそも導入できない場合があるためです。
トレンドマイクロの技術ブログは、この点を次のように説明しています。コンテナイメージ（コンテナの実行テンプレート）という要素や、コンテナ自体の生存期間が短いことから、従来とは異なるアプローチが必要になるという指摘です。
従来のマルウェア対策といえば、サーバに対策ソフトを導入するイメージですが、コンテナではそもそも、従来のマルウェア対策ソフトを導入できないケースがあります。また、コンテナイメージという要素やコンテナ自体の生存期間が短い点なども影響して、異なるアプローチを取る必要がある、あるいは取ったほうが良い、ということを心掛けください。
出典：スッキリ、繋げて、コンテナセキュリティを得意分野に！ #3｜トレンドマイクロ（公式技術ブログ）
理由は、大きく3つに整理できます。
- コンテナが起動と破棄を短時間で繰り返すため、エージェントを常駐させてフルスキャンを回す運用が成立しにくい。
- コンテナを一度作ったら書き換えずに使う「イミュータブル（不変）」な運用と、頻繁な定義ファイル更新を前提とする常駐型アンチウイルスの相性が悪い。
- AWS Fargate（サーバー管理をクラウドに任せるコンテナ実行環境）のように、ホストに手が届かずエージェントを置けない構成が存在する。
そのため、コンテナでは「サーバーに1本アンチウイルスを入れて終わり」ではなく、イメージを作る段階から実行中までを分けて守る発想に切り替える必要があります。チェックシートの「アンチウイルス常駐」項目には、この層ごとの対策セットで同等の目的を満たしていると説明するのが実態に合います。
コンテナにマルウェアが入る3つのタイミング（ビルド・デプロイ・実行時）
ここからは、対策を考えるための座標軸として、マルウェアがコンテナに入り込むタイミングを整理します。混入経路は大きく3つに分かれ、それぞれで有効な対策が変わります。
- ビルド時（デプロイ前）：ベースイメージや取り込む依存ライブラリに、最初からマルウェアや不正なコードが混入しているケースです。素性の分からないイメージや改ざんされた公開イメージを土台にすると起こります。
- デプロイ時：レジストリ（イメージの保管庫）からの取得時に、改ざんされたイメージやなりすましイメージをつかまされるケースです。デプロイ時に外部からスクリプトをダウンロードして実行する仕込みもここに含まれます。
- 実行時（デプロイ後）：稼働中のコンテナのファイルシステムに、後からマルウェアが書き込まれたり、ダウンロードされて実行されたりするケースです。Webアプリがユーザーからのファイルアップロードを受け付ける場合は、アップロードされた不正ファイルが実行時の混入経路になることもあります。
トレンドマイクロの技術ブログは、これらに共通する点として「実際にマルウェアが活動をするのは稼働中のコンテナ環境であること」を挙げています。そのため、ビルド時にできる限り持ち込みを防ぎつつ、実行時に発火する脅威への備えも欠かせません。
この3つは「どこで混入するか」を整理する座標軸です。対策そのものは、イメージ対策（ビルド〜デプロイ前のスキャンと署名・出所検証）とランタイム対策（実行時の検知）の2系統に、配置・実行を起こしにくくする間接対策を加えた形にまとまります。デプロイ時のなりすまし・改ざんへの備えは、このうちイメージの署名・出所検証（後述の間接対策）が担います。
一括ダウンロードする
【一望表】層 × 手段 × 代表ツールで見るコンテナのマルウェア対策の全体像
ここでは、3つのタイミングで取る対策と代表的な手段を1枚にまとめます。自社の構成でどこに穴があるかを確認する地図として使ってください。以降の各セクションは、この表の行を掘り下げる形で解説します。
| 系統（層） | イメージ対策（ビルド〜デプロイ前） | イメージ対策（ビルド〜デプロイ前） | イメージ対策（デプロイ時） | ランタイム対策（実行時） | ランタイム対策（実行時） | 間接対策（横断） |
|---|---|---|---|---|---|---|
| 対策 | イメージのマルウェアスキャン（静的・動的） | イメージの脆弱性（CVE）スキャン | イメージの署名・出所検証 | ランタイムのマルウェア検知・ドリフト検知 | 挙動・プロセス・通信の監視 | リードオンリー化・最小イメージ・権限と通信の制御 |
| 守る対象・何をするか | イメージ内の既知マルウェア・不正ファイルをパターン照合（静的）、サンドボックスで挙動確認（動的） | 依存パッケージ・OSの既知脆弱性を検出（マルウェア検出とは別の機能） | 改ざん・なりすましイメージを排除し、検証済みイメージだけをデプロイ | 稼働中に書き込まれた不正バイナリ、イメージに無いバイナリの実行を検知・ブロック | 不審なプロセス実行や通信先を検知し調査につなげる | 混入・発火の前提そのものを減らす |
| 代表的なツール・手段 | ClamAV・YARA（OSS）／Trend Micro Artifact Scanner（SaaS）／商用コンテナセキュリティSaaS（動的スキャン） | Trivy・Grype（OSS）／Amazon ECR・Amazon Inspector（クラウド純正）／Aikido Security（SaaS） | Cosign・Sigstore（OSS）／各レジストリの署名・検証機能 | Microsoft Defender for Containers・Amazon GuardDuty Runtime Monitoring・Google Cloud Container Threat Detection（クラウド純正）／Sysdig・Aikido Security の Runtime Protection（SaaS）／Falco（OSS） | Falco（OSS）／各ランタイムセキュリティSaaS | ReadonlyRootFilesystem・Distroless・マルチステージビルド・CIS Benchmarks |
イメージ対策には、マルウェアを探すスキャンと、既知脆弱性（CVE）を探す脆弱性スキャンがあります。この2つは目的が異なり、ツールも分かれる点が混同しやすいところです。各手段の詳細と出典は、以降の各セクションで順に解説します。
ビルド時の対策：コンテナイメージのマルウェアスキャン（静的・動的）をCIに組み込む
ここからは、ビルド時にできる対策の中心であるイメージスキャンを解説します。イメージスキャンには、ファイルを調べる静的スキャンと、実際に動かして確かめる動的スキャンの2種類があります。
静的スキャンと動的スキャンはどう違うか
静的スキャンは、コンテナイメージの各レイヤにあるファイルを、マルウェアのパターン（シグネチャ）と突き合わせて判別する方式です。トレンドマイクロの技術ブログは、静的スキャンの対象と限界を次のように記しています。
①コンテナイメージに対する静的スキャン … 留意点：ファイルレスマルウェアや実際の挙動を見ての判別でない、また、あくまでもコンテナイメージ内に格納されているファイルが対象
出典：スッキリ、繋げて、コンテナセキュリティを得意分野に！ #3｜トレンドマイクロ（公式技術ブログ）
一方の動的スキャンは、イメージをサンドボックス（隔離した検証環境）で実際に動作させ、不審な挙動がないかを見ます。デプロイ時に外部からスクリプトをダウンロードして実行するような仕込みを、本番投入前に発見できる点が静的スキャンとの違いです。
動的スキャンを単体で提供するOSSは乏しく、商用のコンテナセキュリティSaaSやサンドボックス製品の一機能として提供されるのが一般的です。まずは静的スキャンをCIに組み込み、必要に応じて動的スキャンを足す、という順で検討するとよいでしょう。
CI/CDパイプラインへの組み込みとレジストリでのスキャン
イメージスキャンは、ビルドのたびに自動で走るよう、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに組み込むのが基本です。
イメージそのものに対するマルウェアスキャンの手段としては、Trend Micro Artifact Scanner（TMAS）があります。TMASはコマンドラインから、脆弱性・マルウェア・シークレット（認証情報の混入）を任意に組み合わせてスキャンでき、ローカルのイメージだけでなくレジストリ上のイメージも対象にできます。
出典・参考資料（1件）
- 参考資料：Trend Vision One Artifact Scanner (TMAS) CLI｜トレンドマイクロ（公式ドキュメント）
ここで押さえておきたいのが、Amazon ECR（AWSのコンテナレジストリ）のイメージスキャンとの違いです。ECRのイメージスキャンは、依存パッケージやOSの既知脆弱性（CVE）を検出する脆弱性スキャンであり、マルウェアを探す機能ではありません。
AWSの公式ドキュメントでも対象は「software vulnerabilities」と明記されています。脆弱性対策としては有効ですが、マルウェア対策としては別の手段が必要になります。
出典・参考資料（1件）
- 出典：Scan images for software vulnerabilities in Amazon ECR｜Amazon Web Services（公式ドキュメント）
ここで切り分けた既知脆弱性（CVE）への対応は、マルウェア対策とは別に継続して回す必要があります。コンテナを含む対象の脆弱性を検出し、検出後の優先順位付けまで仕組み化するツールの選び方は、以下の記事で比較しています。
OSSでどこまでできるか
OSS（オープンソースソフトウェア）では、アンチウイルスエンジンのClamAVが代表格です。ClamAVはウイルス・ワーム・トロイの木馬など多数のマルウェアを検出でき、イメージを展開してファイルをスキャンする用途に転用されています。
YARAやYaraHunterといったルールベースの検出ツールと組み合わせる例もあります。ClamAVはシグネチャ（既知のパターン）に基づくため、検知の精度はシグネチャの質と更新に左右される点を理解しておく必要があります。
出典・参考資料（1件）
- 参考資料：ClamAV Documentation｜Cisco Talos（公式ドキュメント）
また、ClamAVはイメージの検査だけでなく、Webアプリがユーザーから受け取るアップロードファイルの検査にも使われます。アプリ本体とは別にClamAVをサイドカー（同じPod〈Kubernetesでコンテナをまとめる最小単位〉内で補助的に動くコンテナ）として動かし、アップロードされたファイルを保存・処理する前にスキャンする構成が代表的です。
この構成により、実行時にユーザー経由で入り込むマルウェアを、保存・処理の前に止められます。
実行時（ランタイム）の対策：稼働中コンテナのマルウェア検知・ドリフト検知
続いて、実行中のコンテナを守るランタイムの対策を解説します。イメージスキャンをすり抜けて実行時に書き込まれる脅威や、稼働後にダウンロードして実行されるマルウェアは、イメージを調べるだけでは拾えないためです。
ドリフト検知（イメージに無いバイナリの実行を捉える）
ランタイムの代表的な考え方が「ドリフト検知」です。これは、元のイメージには無かったバイナリ（実行ファイル）が稼働中のコンテナで動こうとした瞬間を捉える方法を指します。Microsoft Defender for Containers（マイクロソフトのコンテナ向けセキュリティ機能）は、この考え方に基づく既定ルールを備えています。公式ドキュメントは次のように説明しています。
コンテナー ランタイムマルウェア対策は、悪意があると識別された実行可能ファイルをコンテナーが実行するときに、マルウェアを検出してブロックします。（中略）
出典：コンテナー ランタイムのマルウェア対策の検出とブロック｜Microsoft Learn（公式ドキュメント）Malware alert on binaries not originated from original image: システムがドリフトしたバイナリを検出する場合に推奨されるルール。
この機能は検出時に「アラート」「ブロック」「無視」のいずれかを設定でき、Azure Kubernetes Service（AKS）だけでなく、Amazon EKS・Google GKEといったマルチクラウドのKubernetesでも利用できます。特定のクラウドに閉じた機能ではない点が実務では重要です。
ホストに手が届かないFargateでのランタイム検知
Fargateのようにホストへエージェントを置けない構成でも、ランタイムのマルウェア検知は可能です。
Sysdigのブログは、ホストレベルのエージェントをデプロイできない制約を認めています。そのうえで、悪意のあるバイナリがコンテナのファイルシステムに書き込まれた時点や、不審なプロセスが実行されようとした時点で検知できると説明しています。既知シグネチャによるハッシュ検知と、挙動に基づく検知を組み合わせる方式です。
出典・参考資料（1件）
- 参考資料：AWS Fargate におけるランタイムマルウェア検知｜Sysdig（公式ブログ）
AWS純正では、Amazon GuardDuty Runtime Monitoringが、OSレベル・ネットワーク・ファイルのイベントを観測して脅威を検知します。シグネチャ型のマルウェア検出というより、挙動から不審なバイナリの実行などを捉える方式です。
対応リソースはEKS・EC2に加えてECS on Fargateが含まれますが、EKS on Fargateは対象外である点に注意が必要です。自社のFargateの使い方（ECSかEKSか）で選べる手段が変わります。
出典・参考資料（1件）
- 出典：GuardDuty Runtime Monitoring｜Amazon Web Services（公式ドキュメント）
イメージスキャンとランタイム検知はどう使い分けるか（両方そろえる理由）
ここまで見たビルド時のイメージスキャンと、実行時のランタイム検知は、どちらか一方で足りるものではありません。守備範囲が異なり、片方だけでは穴が残るためです。
イメージスキャンは、本番に出す前にイメージ内のファイルを調べる予防策です。デプロイ前に問題を止められる利点がある一方、対象はあくまでイメージに格納されたファイルで、稼働後に外部から書き込まれるマルウェアや、メモリ上だけで動くファイルレスマルウェアは守備範囲の外になります。
ランタイム検知は、まさにこの「実行時に起きること」を捉える役割です。稼働中に書き込まれた不正バイナリや、イメージに無いバイナリの実行を検知します。
Sysdigも「イメージスキャンは依然として重要な予防的対策ですが、ランタイムでの脅威検知には不十分です」と述べています。したがって実務では、ビルド時に持ち込みをできる限り減らし、実行時にすり抜けや後からの混入を検知する、二層でそろえるのが基本の形になります。片方しか用意できない場合も、まず自社の構成で最も穴になりやすい層から着手するのが現実的です。
混入・発火を防ぐ間接対策（リードオンリー・最小イメージ・署名・権限と通信の制御）
検知・駆除とあわせて、そもそもマルウェアを配置・実行させにくくする間接対策も効果的です。トレンドマイクロの技術ブログは間接対策を13項目に整理していますが、ここでは読者が着手しやすい形に束ね直して紹介します。
- リードオンリー化：コンテナのルートファイルシステムを読み取り専用にして、実行中のファイル書き込みを封じます。Kubernetesではコンテナの
readOnlyRootFilesystem（ルートファイルシステムを読み取り専用でマウントする設定）で指定できます。 - 最小イメージ：不要なシェルやパッケージマネージャを含めないことで、侵入後にできることを減らします。Distroless（アプリと実行時の依存のみを含む軽量イメージ）や、マルチステージビルド（ビルド用の中間ファイルを最終イメージから除くビルド手法）が代表的です。
- イメージの署名・出所検証：信頼できる発行元が署名した、検証済みのイメージだけをデプロイします。Cosign・Sigstore などの署名ツールや各レジストリの署名・検証機能を使い、改ざんやなりすましのイメージをつかまされるリスクを下げられます。これはデプロイ時の改ざん・なりすましへの主な備えになります。
- 権限とアクセスの制御：Docker APIの不要な公開を無効にし、オーケストレーターやホストへのアクセスを絞ります。
- 通信先の制限：コンテナの通信先を必要な範囲に絞り、不審な外部通信を出口で検知・遮断します。
こうした設定の拠り所としては、CIS（Center for Internet Security）が公開するDockerやKubernetes向けのベンチマークが参考になります。コミュニティの合意にもとづくセキュア設定のガイドラインで、自社の設定が妥当かを点検する基準として使えます。
出典・参考資料（3件）
一括ダウンロードする
自分の環境では何から入れるか（AWS・Azure・Kubernetes/ECS/Fargate別の当てはめ）
ここからは、代表的な環境ごとに「何から入れるか」を整理します。使っているクラウドやオーケストレーターで、選べる手段と着手の順番が変わるためです。
AWS（ECS／EKS／Fargate）の場合
ビルド時は、ECRの脆弱性スキャン（Amazon Inspectorと連携した継続的なCVE検査）を有効にしつつ、マルウェアのスキャンはTMASなどイメージのマルウェア検査に対応した手段をCIに組み込みます。
実行時は、Amazon GuardDuty Runtime Monitoringが有力です。前述のとおりECS on Fargateには対応しますがEKS on Fargateは対象外のため、EKS on Fargateでランタイム検知が必要な場合は、Sysdigなどホスト不可達構成に対応するSaaSを検討します。
Azure／マルチクラウドのKubernetesの場合
Microsoft Defender for Containersは、ランタイムのマルウェア検知（ドリフトしたバイナリの検知）をAKS・Amazon EKS・Google GKEで利用できます。Azureだけでなく他クラウドのKubernetesにも適用できるため、複数クラウドにまたがる環境で検知方針をそろえたい場合に候補になります。
GKEを使う場合は、Google Cloud純正のContainer Threat Detection（Security Command Centerの一機能）という手段もあります。稼働中のコンテナでイメージに無いバイナリが実行された、リバースシェル（攻撃者が外部から操作するための通信）が張られた、といった実行時の脅威を検知します。
自前のKubernetes／ECSの場合
クラウド純正の検知に頼れない自前運用では、OSSのFalco（ランタイムの挙動検知）やClamAV（イメージのマルウェアスキャン）を組み合わせる選択肢があります。あわせて、リードオンリー化や最小イメージ、権限の制御といった間接対策を設定で効かせると、検知に頼りきらない多層防御になります。運用の手間を抑えたい場合は、次に述べるSaaSに委ねる判断も現実的です。
OSSでどこまでできて、どこからSaaS/マネージドに任せるか
最後に、自前のOSSと、委託するSaaS／マネージドサービスの線引きを考えます。どちらが正解というより、運用にかけられる手間とコストで決める問題です。
OSSは、ClamAVやFalcoのように無償で始められ、CIに組み込みやすい利点があります。ビルド時のイメージスキャンやフォレンジック（侵害調査）には低コストで役立ちます。一方で、シグネチャやルールの整備・更新、検知した後の運用（誤検知の調整、アラートの切り分け）は自社で担う必要があり、実行時の常時監視まで自前でそろえると運用負荷が大きくなります。
そこで、イメージ検査から実行時の保護までを1つの管理画面でまかなえるSaaSに任せる選択肢が現実的になります。特に、コンテナイメージの検査と稼働中のランタイム保護を併せ持ち、依存ライブラリやクラウド設定まで含めてまとめて見られるサービスは、個別のOSSを組み合わせる手間を省けます。次のセクションで、その一例を紹介します。
コンテナのマルウェア対策を実行する手段：イメージ検査とランタイム保護を備えた脆弱性診断SaaS
ここでは、コンテナのマルウェア対策に使える主なサービス・製品を俯瞰したうえで、イメージ検査と実行時の保護をまとめて担える脆弱性診断SaaSとして、Aikido Securityを紹介します。
本記事で挙げた主なサービス・製品を、担う役割と対応環境で整理した比較表です。有償サービス・クラウド純正を中心にまとめています。ClamAVやFalcoなどOSSを含む全体像は、前掲の一望表をご覧ください。
| サービス名 | Aikido Security | Microsoft Defender for Containers | Amazon GuardDuty Runtime Monitoring | Google Cloud Container Threat Detection | Sysdig | Trend Micro Artifact Scanner（TMAS） |
|---|---|---|---|---|---|---|
| 主な役割 | イメージ検査＋ランタイム保護 | ランタイム検知（ドリフトしたバイナリの検知） | ランタイム検知（OS・プロセス・通信の観測） | ランタイム検知（イメージに無いバイナリ・リバースシェル等） | ランタイム検知（Fargate対応） | イメージのマルウェアスキャン（CI・レジストリ対応） |
| 主な対応環境 | マルチクラウド（AWS・Azure・GCP等） | AKS・EKS・GKE | EKS・ECS on Fargate・EC2（EKS on Fargateは対象外） | GKE | Kubernetes・AWS Fargate | イメージ・レジストリ |
| 提供形態 | SaaS | クラウド純正 | クラウド純正 | クラウド純正 | SaaS | SaaS |
| 詳細情報 | 公式資料を見る | 公式サイト | 公式サイト | 公式サイト | 公式サイト | 公式サイト |
各サービスの公式情報・公式ドキュメントをもとに作成（2026年11月時点）。最新の対応範囲は各公式情報をご確認ください。
Aikido Security（Aikido Security BV／日本窓口：株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査するSaaSです。人が診断してレポートを納める受託型ではなく、自動スキャンを利用する契約形態で、開発会社・開発部門を主な対象としています。
コンテナのマルウェア対策の観点では、コンテナイメージの検査（Container Images）と、実行中の保護を担うランタイム保護（Runtime Protection）を製品群に備えます。依存ライブラリなど開発環境を狙うマルウェアの検出（Malware Detection）も扱いますが、これはコンテナ実行時のマルウェアとは別領域の機能です。
イメージ検査と実行時の保護、さらに依存ライブラリやクラウド設定の点検までを1つのサービスでカバーできるため、OSSを個別に組み合わせる手間を抑えたい場合の選択肢になります。
料金は、無料で試せるDeveloperプランから段階が用意されています。日本窓口の株式会社AndGoでは、日本円の請求書払いに対応し、年間契約・利用者10人までの参考価格として月額5万円台からの案内があります（2026年11月時点。最新の料金は要問い合わせ）。
製品本体のサポートは英語が基本で、日本語での導入・運用の一次対応はAndGoが担います。実際の対象機能や料金は契約経路によって異なるため、導入時はAndGoへの確認をおすすめします。
イメージ検査やマルウェア検出を開発工程に組み込むという考え方について、日本窓口である株式会社AndGoの原氏は、セキュリティの担い方の変化を次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
ここで取り上げたAikido Securityは選択肢の一例です。診断方法や費用、診断後のサポートまで含めて脆弱性診断サービスを広く見比べて選びたい場合は、主要サービスを横断比較した以下の記事もあわせてご覧ください。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
本記事では、コンテナのマルウェア対策を、従来のアンチウイルスが通用しない理由から、層ごとの具体的な手段、環境別の当てはめまで整理しました。
要点は、混入タイミング（ビルド・デプロイ・実行時）を座標軸に、イメージ対策とランタイム対策の2系統で守ることです。イメージ対策はビルド〜デプロイ前のマルウェアスキャン・脆弱性スキャン・署名検証、ランタイム対策は実行時のドリフト検知などが中心になります。この2系統に間接対策（リードオンリー化や最小イメージ）を加えると、検知に頼りきらない多層防御になります。
自社の環境で最も穴になりやすい層から着手し、運用負荷に応じてOSSとSaaSを使い分けるのが現実的な進め方です。
MCB FinTechカタログでは、コンテナのイメージ検査やランタイム保護に対応した脆弱性診断サービスの資料を無料で請求できます。対応する検査範囲を見比べて、自社の環境に合うサービスの検討を進めてください。
一括ダウンロードする
よくある質問（FAQ）
Q. コンテナのマルウェア対策とは何ですか？
A. コンテナのマルウェア対策とは、ビルド時・デプロイ時・実行時という3つのタイミングに分けて、イメージのスキャンと稼働中コンテナの検知を組み合わせて守る取り組みです。ホストにアンチウイルスソフトを1本常駐させる従来の方式は、起動と破棄が速くイミュータブルに運用されるコンテナには素直に当てはまりません。
そのため、ビルド時にイメージのマルウェアスキャンと脆弱性スキャンをCIに組み込み、実行時にドリフト検知などのランタイム保護を置く、という層ごとの対策セットで守るのが基本になります。
Q. Amazon ECRのイメージスキャンでコンテナのマルウェアも検出できますか？
A. Amazon ECRのイメージスキャンは依存パッケージやOSの既知脆弱性（CVE）を検出する脆弱性スキャンで、マルウェアを検出する機能ではありません。AWSの公式ドキュメントでも対象は「software vulnerabilities」と明記されています。
コンテナイメージ内のマルウェアを検査したい場合は、Trend Micro Artifact Scanner（TMAS）やClamAVなど、マルウェア検査に対応した手段を別途CIに組み込む必要があります。脆弱性スキャンとマルウェアスキャンは目的の異なる別の対策だと整理してください。
Q. AWS Fargateでもコンテナのマルウェアをランタイムで検知できますか？
A. AWS Fargateでもランタイムのマルウェア検知は可能ですが、ECS on FargateかEKS on Fargateかで使える手段が変わります。AWS純正のAmazon GuardDuty Runtime MonitoringはECS on Fargateに対応する一方、EKS on Fargateは対象外です。
EKS on Fargateのようにホストへエージェントを置けない構成でランタイム検知が必要な場合は、Sysdigなどホスト不可達構成に対応するSaaSが選択肢になります。自社のFargateの使い方（ECSかEKSか）を確認したうえで手段を選んでください。
Q. セキュリティチェックシートの「アンチウイルスソフト常駐」要件に、コンテナ環境ではどう答えればよいですか？
A. コンテナ環境では、ビルド時のイメージスキャンと実行時のランタイム検知を組み合わせた層ごとの対策セットで、同等の目的を満たしていると説明するのが実態に合います。コンテナは起動・破棄が速く、イミュータブルに運用し、Fargateのようにホストへエージェントを置けない構成もあるため、ホストに1本アンチウイルスを常駐させる従来方式がそのまま成立しないケースがあります。
「常駐型アンチウイルスは導入していないが、イメージのマルウェアスキャンとランタイムのマルウェア検知で同等の保護を実現している」と、採用している具体的な手段とあわせて回答するのが現実的です。
Q. コンテナのマルウェア対策はOSSだけで完結できますか？
A. OSSだけでもビルド時のイメージスキャンや侵害調査（フォレンジック）は低コストで始められますが、実行時の常時監視まで自前でそろえると運用負荷が大きくなります。ClamAV（イメージのマルウェアスキャン）やFalco（ランタイムの挙動検知）は無償で始められCIにも組み込みやすい一方、シグネチャやルールの整備・更新、誤検知の調整やアラートの切り分けは自社で担う必要があります。
運用にかけられる手間とコストを踏まえ、イメージ検査から実行時の保護までを1つの管理画面でまかなえるSaaSに任せる範囲を決めるのが現実的です。
Q. ファイルレスマルウェアはコンテナのイメージスキャンで検知できますか？
A. ファイルレスマルウェアは、イメージ内のファイルを調べる静的なイメージスキャンでは検知できません。静的スキャンの対象はあくまでコンテナイメージ内に格納されたファイルで、実際の挙動を見るものではないためです。
メモリ上だけで動くファイルレスマルウェアや、稼働後に外部から書き込まれるマルウェアは、実行時の挙動を捉えるランタイム検知が守る領域になります。イメージスキャンだけでは拾えない脅威がある点を押さえておくとよいでしょう。
コンテナのマルウェア対策に役立つ脆弱性診断サービスの資料を一括チェック
MCB FinTechカタログでは、コンテナのイメージ検査やランタイム保護に対応した脆弱性診断サービスの資料を無料で一括請求できます。対応する検査範囲や料金を比べて、自社の環境に合う一社を選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
