自社のWebサービスや社内システムをDocker・Kubernetesのコンテナで動かすようになり、「従来のサーバとは守り方が変わるのではないか」「どこから手を付ければよいのか」と不安を感じていませんか。コンテナはアプリと依存関係をまとめて持ち運べる便利さの一方で、イメージの脆弱性や設定ミスなど、これまでにない経路から攻撃を受けるようになります。
攻撃を受けてから慌てないためには、コンテナのどこに・どんな脅威があるのかを段階ごとに把握し、まず何から守るべきかを優先順位とともに押さえておくことが欠かせません。
本記事では、コンテナ特有の脅威をイメージ・レジストリ・実行環境・オーケストレーター・ホストの5段階に整理し、各段階で何が危なく・何をすべきかを「やる順」で解説します。
米国NISTのガイドラインやCISベンチマーク、Kubernetes公式ドキュメントといった公的な基準・公式ドキュメントに各段階の対策を紐付けています。さらに、自社で対応できる範囲と外部の脆弱性診断サービスに任せるべき範囲の切り分けまで扱います。コンテナ運用に関わる開発・インフラ・セキュリティ担当の方が、守り方の全体像を描くための材料としてご活用ください。
目次
一括ダウンロードする
コンテナセキュリティとは？従来サーバ・VMとの違い
コンテナセキュリティとは、コンテナ化されたアプリケーションを、ビルドから配布・実行までのライフサイクル全体で、脆弱性や設定ミス・サイバー攻撃から守るための取り組みを指します。守る対象はコンテナ単体にとどまらず、イメージ・レジストリ・実行環境・オーケストレーター・ホストOSまで広がります。
従来サーバ・仮想マシン（VM）との違い
コンテナはOS仮想化（OSレベルの仮想化）という技術で、各アプリにOSの仮想的なビューを個別に与えて相互に隔離します。米国国立標準技術研究所（NIST）のガイドライン「NIST SP 800-190」は、この仕組みを次のように説明しています。
Operating system (OS) virtualization provides a separate virtualized view of the OS to each application, thereby keeping each application isolated from all others on the server.（OS仮想化は各アプリケーションにOSの個別の仮想ビューを提供し、サーバ上の他のすべてのアプリケーションから隔離する）
出典：NIST SP 800-190「Application Container Security Guide」Executive Summary｜米国国立標準技術研究所（2017年9月）
ここが仮想マシン（VM）との大きな違いです。VMはゲストOSごと丸ごと仮想化するのに対し、コンテナはホストOSのカーネルを共有します。
カーネルを共有する分だけ起動が速く軽量ですが、ホストや他コンテナとの境界はVMより薄く、1つのコンテナの侵害が隣へ波及しうる点に注意が必要です。さらにコンテナは、公開イメージをもとに作られ、頻繁に作り直されて短命である点も従来サーバと異なります。こうした違いが、次章で見る「コンテナ特有の脅威」を生みます。
出典・参考資料（1件）
- 出典：NIST SP 800-190「Application Container Security Guide」｜米国国立標準技術研究所（リンク）
コンテナ特有の脅威はどこにある？段階別の攻撃対象領域マップ
ここからは、コンテナ環境で攻撃を受けうる場所（攻撃対象領域）を段階別に整理します。コンテナを使うと、アプリのコードだけでなく、取り込むイメージ・保管するレジストリ・動かす基盤まで守る範囲が広がり、その分だけ侵入経路も増えます。
NIST SP 800-190は、コンテナ技術の主要なリスクを構成要素ごとに次の5つに区分しています。
This section identifies and analyzes major risks for the core components of container technologies—images, registries, orchestrators, containers, and host OSs.（本章はコンテナ技術の中核コンポーネント＝イメージ、レジストリ、オーケストレーター、コンテナ、ホストOS の主要リスクを特定・分析する）
出典：NIST SP 800-190 §3「Major Risks for Core Components of Container Technologies」｜米国国立標準技術研究所
この5つの区分が、守る範囲のどこに位置するかとあわせて図にすると、全体像は次のようになります。
この区分にそって、各段階に潜む主な脅威を一覧にすると次のとおりです。
| 段階 | 主な脅威（NIST SP 800-190のリスク区分） |
|---|---|
| ①イメージ | 既知の脆弱性・設定不備／マルウェアや認証情報の埋め込み／信頼できないイメージの利用 |
| ②レジストリ | 安全でない接続・古い脆弱なイメージの残存／認証・認可の不備によるイメージの改ざん・なりすまし |
| ③実行環境（ランタイム・コンテナ） | 安全でない設定（特権コンテナ等）／ランタイム侵害によるホスト・他コンテナへの波及（コンテナエスケープ） |
| ④オーケストレーター（Kubernetes） | 無制限な管理者アクセス／コンテナ間通信の分離不足・ワークロードの混在／管理画面・APIの露出 |
| ⑤ホスト（ホストOS） | カーネル共有に起因するリスク／ホストOSの脆弱性・不適切なユーザー権限 |
とりわけ注意したいのが、③実行環境で起こる「コンテナエスケープ」です。NIST SP 800-190は、ランタイムが侵害された場合に起こりうることを次のように述べています。
While an uncommon occurrence, if a container runtime were compromised, an attacker could utilize this access to attack all the containers on the host and even the host itself.（まれではあるが、コンテナランタイムが侵害されると、攻撃者はそのアクセスを使ってホスト上の全コンテナ、さらにはホスト自体を攻撃しうる）
出典：NIST SP 800-190 §5.2「Exploit of the Container Runtime」｜米国国立標準技術研究所
このように、1つのコンテナやランタイムの綻びが、同じホスト上の他のコンテナやホストOSにまで広がる恐れがあります。また、公開レジストリから取り込んだ汚染イメージを実行してしまうと、そこに仕込まれた不正なプログラム（暗号資産の不正マイニングを行うものなど）が動き出す危険もあります。
コンテナエスケープは実際に報告されています。2019年に公表された CVE-2019-5736 は、Docker・containerd・CRI-O・Kubernetes など多くの環境が使う低レベルランタイム runc の脆弱性です。悪意あるコンテナからホスト上の runc 実行ファイルを上書きされ、コンテナの外のホストを root 権限で乗っ取られる恐れがありました。
runc 1.0.0-rc6 までのバージョンが影響を受け、修正版の runc 1.0.0-rc7（2019年3月公開）以降で対処されています（Docker では 18.09.2 以降）。既知の脆弱性をふさぐには、イメージとランタイムを最新に保ち、後述のスキャンと強化を続けることが前提になります。
「ネットワーク」や「過剰な権限」といった論点は独立した脅威というより、③実行環境・④オーケストレーターの各段階に含まれる形で現れます。
出典・参考資料（2件）
段階別の対策とベストプラクティス（やる順・優先度）
ここからは、前章の5段階それぞれで「何をするか」を解説します。対策は数が多いため、まず着手すべき優先順位から押さえましょう。
原則は「早い段階ほど安く確実に潰す」という考え方です。開発の上流（イメージを作る段階）で脆弱性を止めるほど、本番で問題が起きてからの対応より手間もリスクも小さく済みます。これはセキュリティ対策を開発工程の早期に組み込む「シフトレフト」と呼ばれる考え方です。
まず着手すべきは、(1)イメージの脆弱性スキャンをCI（継続的インテグレーション）に組み込む、(2)コンテナを非root・最小権限で実行する、(3)ランタイムの監視を用意する、の3つです。手を付ける順番としては、(1)はビルド時に、(2)はデプロイ時に、(3)は運用を始める前にそれぞれ仕組みを用意し、その後は各段階の対策を積み上げていきます。
段階ごとの「何が危ないか・何をするか・支えるツール種別・着手の優先度」を一覧にすると次のとおりです（表のツール種別の略語は次章「対策を支えるツール種別の整理」で解説します）。
| 段階 | 主な対策（何をするか） | 支えるツール種別 | 優先度 |
|---|---|---|---|
| ①イメージ | 脆弱性・依存関係スキャンをCIに組み込む（シフトレフト）、CVSS値で不合格イメージの進行を止める、ベースイメージの最小化、イメージ署名 | イメージスキャン／SCA（ソフトウェア構成分析） | 最優先（ビルド時） |
| ②レジストリ | 信頼できるレジストリの利用、アクセス制御、取り込み前のイメージ署名の検証 | イメージスキャン／レジストリのアクセス管理 | 高 |
| ③実行環境（ランタイム） | 非root実行・最小権限、読み取り専用ファイルシステム、リソース制限、SELinux／AppArmor（強制アクセス制御）やseccompの活用 | ランタイム保護（CWPP） | 最優先（デプロイ時） |
| ④オーケストレーター（Kubernetes） | Pod Security Standardsで段階的に権限を締める、RBACで最小権限、NetworkPolicyでコンテナ間通信を制御、Admission制御で危険な設定の投入を拒否 | CSPM／Admission Controller／kube-bench等の設定チェック | 高 |
| ⑤ホスト | コンテナ実行に適したホストOSの採用と強化、CISベンチマーク準拠、不要サービスの無効化 | ホストスキャン／構成チェック | 中 |
| 運用フェーズ横断 | ランタイムの監視・異常検知、ログ監査、インシデント対応フローの整備 | ランタイム保護（CWPP）／監視・検知 | 最優先（初期セットアップ）→以後は継続 |
①イメージ：スキャンをCIに組み込む（シフトレフト）
イメージ段階は最優先で手を打つ場所です。NIST SP 800-190は、イメージの脆弱性対策として、ビルドの開始からレジストリ、実行時までライフサイクル全体にスキャンを統合することを推奨しています。あわせて、一定のCVSS（共通脆弱性評価システム）値を超える脆弱性を含むイメージは、ビルド工程で先に進ませないルールを設定できるようにすべきだとしています。
これが「品質ゲート」の考え方で、問題のあるイメージを本番に届く前に止めます。実務では、たとえばCVSSスコア7.0以上（深刻度「High」以上）の脆弱性を含むイメージは不合格とする、といった基準を決めて運用します。あわせて、ベースイメージを必要最小限に絞り、イメージへの署名で改ざんを検知できるようにします。
②レジストリ：信頼できる取得元と署名の検証
レジストリは、取り込むイメージの「取得元」を守る段階です。信頼できるレジストリだけを利用し、アクセス制御で誰がイメージを登録・取得できるかを絞ります。取り込む際にイメージ署名を検証すれば、改ざんされたイメージやなりすましを防げます。古くなった脆弱なイメージを放置しないことも、よくある見落としへの対策になります。
③実行環境（ランタイム）：非root・最小権限で動かす
実行環境は、万一コンテナが侵害されても被害範囲を抑えるための段階です。コンテナをroot権限で動かさない、不要な権限を与えない、ファイルシステムを読み取り専用にする、リソース制限をかける、といった設定で「できることを最小限にする」のが基本です。
具体的には、Dockerfileで実行ユーザーを一般ユーザーに指定する（USER命令）、特権コンテナ（–privilegedオプション）を使わない、といった設定が最小限の着手点になります。
NIST SP 800-190は、ランタイムの安全でない設定への対策として、設定基準への準拠を自動化することと、Linux環境での強制アクセス制御（SELinuxやAppArmor）の活用を挙げています。その技術的な実装ガイダンスとして、CISのDockerベンチマークを名指しで推奨しています。特権コンテナの常用は「よくある設定ミス」の代表例で、避けるべきです。
④オーケストレーター（Kubernetes）：Pod Security・RBAC・NetworkPolicy
Kubernetesでコンテナを束ねて運用する場合、設定項目が多く、どこから締めればよいか迷いがちです。Kubernetes公式はセキュリティを「クラウド・クラスター・コンテナ・コード」の4つの階層（4C）で整理する考え方を示しており、この段階は、そのうちクラスター層とコンテナ層を締める話にあたります。
まずは公式が用意する3段階のポリシー「Pod Security Standards」を基準にするのが分かりやすい方法です。Kubernetes公式はこれを次のように定義しています。
The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive.（Pod Security Standardsは、セキュリティの幅を広くカバーする3つの異なるポリシーを定義する。これらは累積的で、非常に寛容なものから非常に制限的なものまでの範囲をとる）
出典：Pod Security Standards｜Kubernetes公式ドキュメント
3つのポリシーは、Privileged（無制限）、Baseline（既知の権限昇格を防ぐ最小限の制限）、Restricted（現行のPod堅牢化のベストプラクティスに従う強い制限）です。まずはBaselineを満たし、重要なワークロードはRestrictedへ、と段階的に締めていくのが現実的です。
そのうえで、RBAC（ロールベースアクセス制御）で利用者やサービスに最小権限だけを与え、NetworkPolicyでコンテナ（Pod）間の通信を必要な範囲に絞ります。機密度の異なるアプリを同じ仮想ネットワークに同居させると、内部の重要なアプリがネットワーク攻撃にさらされやすくなるためです。さらにAdmission制御を使えば、危険な設定のコンテナがそもそもクラスタに投入されるのを拒否できます。
⑤ホスト：ホストOSの強化とCISベンチマーク準拠
ホストはすべてのコンテナが載る土台です。汎用OSではなくコンテナ実行に適したホストOSを使い、不要なサービスを無効化して攻撃対象領域を減らします。設定の強化基準としては、CIS（Center for Internet Security）がDockerとKubernetesそれぞれのベンチマークを公開しています。
DockerとKubernetesそれぞれにベンチマークがあり、コミュニティの合意にもとづく設定ガイドラインとして、推奨設定を体系的に確認できます。
運用フェーズ横断：検知とインシデント対応
これらの対策を講じても、攻撃を完全にゼロにはできません。そこで、運用フェーズ全体を通じて、ランタイムの振る舞いを監視して異常を検知し、ログを監査し、何かあったときに隔離・調査・復旧へ進めるインシデント対応フローを用意しておきます。コンテナは短命で作り直されるため、問題が起きた瞬間の証拠が残りにくく、継続的な監視の有無が初動の明暗を分けます。
出典・参考資料（6件）
- 出典：NIST SP 800-190 §4「Countermeasures for Major Risks」｜米国国立標準技術研究所（リンク）
- 出典：CIS Docker Benchmark｜Center for Internet Security（リンク）
- 出典：CIS Kubernetes Benchmark｜Center for Internet Security（リンク）
- 出典：Pod Security Standards｜Kubernetes公式ドキュメント（リンク）
- 出典：Using RBAC Authorization｜Kubernetes公式ドキュメント（リンク）
- 出典：Network Policies｜Kubernetes公式ドキュメント（リンク）
対策を支えるツール種別の整理
ここでは、前章の対策表に出たツール種別を補足します。製品名で覚えるより「どの段階の何を守るツールか」で押さえると、自社に足りないものが見えてきます。各種別には、オープンソース（OSS）と商用の代表的なツールがあります。
- イメージスキャン／SCA（ソフトウェア構成分析）：コンテナイメージやアプリが使う依存ライブラリの既知の脆弱性を検出する。①イメージ・②レジストリ段階を守る。代表的なツールにOSSのTrivy・Grype・Clair、商用のSnykなどがある。
- CSPM（クラウドセキュリティ態勢管理）：クラウドやKubernetesの設定ミスを継続的に点検する。④オーケストレーター段階を守る。商用のPrisma Cloud・Wiz、設定点検に使われるOSSのkubescapeなどがある。
- CWPP（クラウドワークロード保護）／ランタイム保護：実行中のコンテナの振る舞いを監視し、異常や攻撃を検知・遮断する。③実行環境・運用フェーズを守る。OSSのFalco、商用のSysdig・Aqua Securityなどが使われる。
- Admission Controller：Kubernetesに危険な設定のコンテナが投入されるのを入口で拒否する。④オーケストレーター段階を守る。OSSのOPA Gatekeeper・Kyvernoなどがある。
- 設定チェック（ベンチマーク準拠）：CISベンチマークなどの基準に沿ってDocker・Kubernetes・ホストの設定を点検する。④・⑤段階を守る。OSSのkube-bench・Docker Bench for Securityなどがある。
近年は、イメージスキャンからクラウド設定、ランタイム保護までを1つのプラットフォームで扱える製品も増えています。これらを自社で導入・運用するか、専門家の診断サービスに任せるかは、次章の切り分けで判断します。個別の製品を比較・選定したい場合は、脆弱性診断サービスの比較記事もあわせて参考にしてください。
自社でやること・外部の診断サービスに任せることの切り分け
ここまでの対策は、すべてを自社だけで抱え込む必要はありません。日々の運用で自社が担う範囲と、専門家の手を借りる範囲を切り分けると、現実的に回せる体制になります。
自社で日常的に回すのが向いている範囲は、開発フローに組み込める部分です。イメージスキャンをCIに組み込む、非root・最小権限で動かす、Pod Security StandardsやRBAC・NetworkPolicyで設定を締める、CISベンチマークで設定を点検する、といった対策は、一度仕組みを作れば日々の開発・運用のなかで継続できます。
一方で、外部の脆弱性診断サービスに任せるのが向いている範囲もあります。自動スキャンだけでは見つけにくいアプリ固有のロジックの穴や、コンテナを含めたシステム全体を網羅的・客観的に確認したい場合、専門のセキュリティエンジニアによる診断が有効です。
また、自社に専門人材が足りない、第三者による診断結果を取引先や監査に示したい、といった場合も外部活用の典型です。次章では、コンテナイメージや稼働中アプリの脆弱性を診断できるサービスを紹介します。
一括ダウンロードする
コンテナの脆弱性を診断できるサービス
コンテナの脆弱性診断には、自動でスキャンし続けるSaaS型（ツールを契約して自社で回す）と、専門エンジニアが網羅的に診断する委託型（診断を依頼して報告書を受け取る）があり、向いている場面が異なります。前章の切り分けを踏まえ、両タイプの代表例を比較表で確認してください。
| サービス名 | Aikido Security | GMO Flatt Security 脆弱性診断 |
|---|---|---|
| 診断方式 | 自動スキャン型（SaaS） ツールを契約し自社で運用 | 専門家による委託型 診断を依頼し報告書を受け取る |
| コンテナの診断 | ●コンテナイメージの検査に対応 | ●「コンテナ」の診断メニューあり |
| 主な診断対象 | ソースコード・依存ライブラリ クラウド設定・コンテナ 稼働中Webアプリ | Webアプリ・API・SPA GraphQL・クラウド・コンテナ Firebase・LLM など |
| 診断範囲・観点 | 既知の脆弱性・設定ミスを 自動検出（SCA/SAST/DAST/CSPM） | OWASP Top 10・ASVS＋ 認証/認可・ビジネスロジックの不備 |
| ソースコード診断 | ●SAST・SCAに対応 | ●標準診断に付帯（追加料金なし） |
| 料金形態 | 月額制（サブスクリプション） | 個別見積もり（範囲に応じ変動） |
| 料金目安 | 月額5万円台〜 （年間契約・利用者10人までの参考価格。要問い合わせ） | 100万円〜（税別） ※見積り無料 |
| 導入前のお試し | 無料プラン・無料トライアルあり | 見積り無料・サンプル報告書DL |
| こんな企業に向く | 開発フローに組み込んで 日常的に自動チェックしたい | 専門家に網羅的・客観的に 診てもらいたい |
| 詳細情報 | 公式資料を見る | サービス詳細を見る |
※料金は2026年11月時点の各社公式情報にもとづく参考値です。最新・正確な金額は各社にご確認ください。
1. Aikido Security（Aikido Security BV／日本窓口：株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査する、自動スキャン型の脆弱性診断SaaSです。
製品群にはクラウド領域の「Container Images（コンテナイメージ）」の検査が含まれ、コンテナイメージの脆弱性をCIに組み込んで継続的にチェックできます。人が診断して報告書を納める受託型ではなく、ツールを契約して自社で回す形態のため、前章でいう「自社で日常的に回す」対策を効率化したい場合に向きます。
SCA（依存関係チェック）・SAST（静的診断）・DAST（動的診断）・CSPM（クラウド設定診断）といった複数の検査を横断的に扱えます。検知アラートを自動でトリアージして誤検知を減らし、Slack・Teams・Jira・AWSなど既存の開発フローと連携できる点も特徴です。
無料のDeveloperプランから始められ、日本語での販売・問い合わせは株式会社AndGoが窓口となり、日本円での請求書払いにも対応しています。
こうした「自社で回す」運用の土台にあるのが、本記事でも触れた、開発の早い段階からセキュリティを組み込むという考え方です。開発現場での変化について、提供元の株式会社AndGo 代表取締役 原氏は次のように話しています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
2. GMO Flatt Security 脆弱性診断（GMO Flatt Security株式会社）
GMO Flatt Security 脆弱性診断は、GMO Flatt Security株式会社が提供する、自社所属のセキュリティエンジニアによる脆弱性診断です。
Webアプリケーションを中心に、API・SPA・GraphQL・クラウド（AWS・Google Cloud・Azure）など幅広い診断メニューを揃えており、そのなかに「コンテナ」の個別メニューがあります。自動スキャンだけでは見つけにくいアプリ固有の穴まで、専門家に網羅的に診てもらいたい場合の委託型の選択肢です。
標準の診断にソースコード診断（部分的なホワイトボックス）が追加料金なしで付く点が特徴で、ブラックボックス診断だけでは届きにくい箇所を補います。診断範囲は、OWASP Top 10やOWASP ASVSで扱われる典型的な脆弱性に加え、認証・認可の不備やビジネスロジックの脆弱性まで及びます。料金やメニューの詳細は、要件に応じた見積もりとなるため公式サイトで確認してください。
ここで挙げた2サービスは、コンテナの脆弱性診断に対応する選択肢の一部です。コンテナに限らず、Webアプリやネットワークまで含めて脆弱性診断サービスを比べたい、診断方式ごとの費用相場や選び方から整理したいという場合は、次のまとめ記事が全体像をつかむ助けになります。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ：段階別に「やる順」で守りを固める
コンテナセキュリティは、守る対象がイメージ・レジストリ・実行環境・オーケストレーター・ホストの5段階に広がる点が、従来サーバとの大きな違いです。まずはイメージスキャンのCI組み込み、非root・最小権限での実行、ランタイム監視の3つを優先的に押さえ、各段階の対策を積み上げていくのが現実的な進め方です。
設定の拠り所としては、NIST SP 800-190、CISのDocker・Kubernetesベンチマーク、Kubernetes公式ドキュメントが信頼できる公式の基準になります。
自社の開発フローで回せる対策は内製で継続し、専門家の目が要る網羅的な診断は外部サービスに任せる、という切り分けを意識すると、無理なく守りを固められます。コンテナを体系的に深く学びたい場合は、NIST SP 800-190やKubernetes公式ドキュメントのほか、技術書『コンテナセキュリティ』（Liz Rice 著）も入り口として役立ちます。
まずは自社のコンテナ運用を5段階で棚卸しし、優先度の高い対策から着手してください。
一括ダウンロードする
よくある質問（FAQ）
Q. コンテナセキュリティとは何ですか？
A. コンテナセキュリティとは、Docker・Kubernetesなどで動かすコンテナ化されたアプリケーションを、ビルドから配布・実行までのライフサイクル全体で脆弱性・設定ミス・サイバー攻撃から守る取り組みです。守る対象はコンテナ単体にとどまらず、イメージ・レジストリ・実行環境・オーケストレーター・ホストOSの5段階に広がる点が、従来のサーバ対策との大きな違いです。
Q. コンテナセキュリティは従来のサーバやVMのセキュリティと何が違いますか？
A. コンテナセキュリティが従来のサーバ・仮想マシン（VM）と最も違うのは、コンテナがホストOSのカーネルを共有するため、1つのコンテナの侵害が同じホスト上の他コンテナやホスト自体へ波及しやすい点です。
VMはゲストOSごと丸ごと仮想化して境界が厚いのに対し、コンテナは軽量・高速な代わりに境界が薄く、さらに公開イメージをもとに作られ短命で頻繁に作り直されます。そのため、イメージの脆弱性や設定ミスといったコンテナ特有の経路への備えが新たに必要になります。
Q. コンテナセキュリティ対策は、まず何から始めればよいですか？
A. コンテナセキュリティは、(1)イメージの脆弱性スキャンをCI（継続的インテグレーション）に組み込む、(2)コンテナを非root・最小権限で実行する、(3)ランタイムの監視を用意する、の3つから着手するのが現実的です。
対策は数が多いため、「早い段階ほど安く確実に潰す」を原則に、まずは開発の上流でイメージの問題を止めることを優先し、そこからレジストリ・オーケストレーター・ホストの対策を積み上げていきます。
Q. シフトレフトとは何ですか？
A. シフトレフトとは、セキュリティ対策を開発工程のできるだけ早い段階（上流）に組み込む考え方です。コンテナでは、イメージを作るビルド段階で脆弱性スキャンを行い、一定の深刻度を超える脆弱性を含むイメージを本番に届く前に止めるほど、運用後に問題が発覚してから対応するよりも手間もリスクも小さく済みます。
Q. Kubernetesのセキュリティの4C（4つのC）とは何ですか？
A. 4C（4つのC）とは、Kubernetes公式ドキュメントがセキュリティを階層で考える枠組みとして示す「クラウド・クラスター・コンテナ・コード」の4つの階層です。
いちばん外側のクラウドから内側のコードへと層が積み重なり、内側のコードの安全は外側の各層の堅牢さに支えられる、という整理です。ただしKubernetes公式はこのモデルを「実証済みのセキュリティポリシーではなく提案」と位置づけているため、絶対の正解としてではなく、守るべき範囲を見渡すための視点として活用するとよいでしょう。
Q. コンテナエスケープとは何ですか？
A. コンテナエスケープとは、攻撃者がコンテナの隔離を破り、ホストOSや同じホスト上の他のコンテナにまでアクセスを広げる攻撃です。NIST SP 800-190は、まれではあるがコンテナランタイムが侵害されると、そのアクセスを使ってホスト上の全コンテナ、さらにはホスト自体が攻撃されうると指摘しています。非root・最小権限での実行やランタイムの監視が、被害の波及を抑える鍵になります。
Q. コンテナを非root・最小権限で動かすべきなのはなぜですか？
A. コンテナを非root・最小権限で動かすべきなのは、万一コンテナが侵害されても、攻撃者にできることを最小限に抑え、ホストや他コンテナへの被害の波及を防ぐためです。
root権限での実行や特権コンテナの常用は代表的な設定ミスにあたります。あわせて、ファイルシステムの読み取り専用化・リソース制限・SELinuxやAppArmorといった強制アクセス制御を組み合わせると、実行環境（ランタイム）の守りが固まります。
Q. コンテナセキュリティにはどのようなツールが使われますか？
A. コンテナセキュリティでは、イメージスキャン／SCA（ソフトウェア構成分析）、CSPM（クラウドセキュリティ態勢管理）、CWPP（ランタイム保護）、Admission Controller、CISベンチマークに沿った設定チェックなど、守る段階ごとに異なる種別のツールが使われます。
製品名で覚えるよりも「どの段階の何を守るツールか」で押さえると、イメージ・レジストリ・オーケストレーター・実行環境のうち自社に足りない備えが見えてきます。
Q. コンテナイメージはどこから入手すれば安全ですか？
A. コンテナイメージは、信頼できるレジストリだけを利用し、取り込む際にイメージ署名を検証することで、改ざんやなりすましを防げます。公開レジストリから取り込んだ汚染イメージを実行すると、暗号資産の不正マイニングなどを行うマルウェアが動き出す危険があります。誰がイメージを登録・取得できるかをアクセス制御で絞り、古くなった脆弱なイメージを放置しないことも重要です。
Q. コンテナセキュリティの対策は、自社だけで対応できますか？
A. コンテナセキュリティは、開発フローに組み込める対策（CIでのイメージスキャン、非root・最小権限での実行、Pod Security StandardsやRBAC・NetworkPolicy、CISベンチマークでの設定点検）は自社で日常的に回せますが、自動スキャンでは見つけにくいアプリ固有の穴や、第三者による網羅的・客観的な確認は外部の脆弱性診断サービスに任せるのが向いています。
自社に専門人材が足りない場合や、診断結果を取引先・監査に示したい場合も、外部活用が有効です。
Q. コンテナセキュリティで参考にすべき公的なガイドラインはありますか？
A. コンテナセキュリティの拠り所としては、NIST SP 800-190（Application Container Security Guide）、CISのDocker・Kubernetesベンチマーク、Kubernetes公式ドキュメントが信頼できる公式の基準になります。
NISTはイメージ・レジストリ・オーケストレーター・コンテナ・ホストOSの5区分でリスクと対策を示し、CISは設定強化の具体的な推奨、Kubernetes公式はPod Security StandardsやRBAC・NetworkPolicyの正確な仕様を確認できます。
Q. 対策をしていても、コンテナが攻撃を受けることはありますか？
A. 十分な対策を講じても、コンテナへの攻撃を完全にゼロにはできないため、ランタイムの継続的な監視と異常検知を前提に備えておく必要があります。コンテナは短命で作り直されるため、問題が起きた瞬間の証拠が残りにくいという特性があります。ログ監査やインシデント対応フローをあらかじめ用意しておくことが、侵害が起きたときの初動の明暗を分けます。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナや稼働中アプリの脆弱性を診断できるサービスの最新資料を無料で一括請求できます。診断範囲・方式・サポート体制を見比べて、自社に合う依頼先を効率的に探せます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
