DockerやKubernetesに代表されるコンテナは、アプリケーションをすばやく構築・配布・実行するための標準的な基盤になりました。一方で、脆弱性を抱えたまま公開されたイメージや、権限を絞らないまま動くコンテナは、攻撃者にとって格好の侵入口になります。コンテナセキュリティとは、こうしたイメージの作成から配布、実行までの各段階でリスクを下げる取り組みの総称です。
本記事では、コンテナのセキュリティ対策を、イメージを作るビルド、レジストリでの配布、脆弱性スキャン、そして実行（ランタイム）まで、コンテナのライフサイクルに沿って一覧で整理します。各対策には、Dockerfileやコマンドの実例と、Docker・AWSの公式ドキュメントやNIST・OWASPのガイドラインを出典として添えます。
「結局どこまでやればいいのか」を領域別のチェックリストで把握し、自社のコンテナ構成に抜けがないかを突き合わせられる構成にしました。最後に、Docker単体・Kubernetes・AWSのマネージド基盤それぞれで、どこまでが基盤側の責任でどこからが自社の責任になるのかも整理します。
目次
一括ダウンロードする
コンテナセキュリティ対策の全体像
コンテナのセキュリティ対策は、思いついた順に手を付けると抜け漏れが生まれます。まずは全体像を、コンテナがたどる流れ（ライフサイクル）に沿って領域ごとに押さえるのが近道です。
クラウドネイティブ技術の標準化団体であるCNCF（Cloud Native Computing Foundation）は、アプリケーションのライフサイクルを開発（Develop）・配布（Distribute）・デプロイ（Deploy）・実行（Runtime）の4段階で整理しています。
本記事もこの考え方にならい、イメージを作るビルド段階、レジストリでの配布、デプロイ前の脆弱性スキャン、そして実行段階という流れで対策を並べます。全体像は次の図のとおりです。
次の表は、各段階で押さえたい代表的な対策の一覧です。自社の構成と照らし合わせ、抜けている項目があれば該当セクションで詳細を確認してください。
| 段階 | 対策 | 詳細 |
|---|---|---|
| ビルド（イメージ） | 最小ベースイメージ（distroless／scratch）の採用 | ビルドの対策 |
| 非rootユーザーでの実行 | ビルドの対策 | |
| イメージ署名と検証 | ビルドの対策 | |
| シークレットをイメージに埋め込まない | ビルドの対策 | |
| Dockerfileの静的解析 | ビルドの対策 | |
| 配布（レジストリ） | イミュータブルタグ | 配布の対策 |
| レジストリのアクセス制御 | 配布の対策 | |
| 保存時の暗号化 | 配布の対策 | |
| 信頼できるイメージの利用 | 配布の対策 | |
| 脆弱性スキャン | イメージの脆弱性スキャン | スキャンとCI組み込み |
| CI／CDへの組み込み（シフトレフト） | スキャンとCI組み込み | |
| デプロイ後の継続的な再スキャン | スキャンとCI組み込み | |
| 実行（ランタイム） | capabilityの削減・特権コンテナの回避 | 実行時の対策 |
| 読み取り専用ルートファイルシステム | 実行時の対策 | |
| seccomp／AppArmorによるシステムコール制限 | 実行時の対策 | |
| ネットワーク分離・最小化 | 実行時の対策 | |
| リソース制限・Dockerソケットの非マウント | 実行時の対策 | |
| 実行時の監視・異常検知・インシデント対応 | 実行時の対策 | |
| 横断（運用・体制） | 実行環境ごとの責任分界の把握 | 責任分界 |
| 優先順位をつけた段階的な導入 | 優先順位 |
これらの対策は、CIS Docker BenchmarkやCIS Kubernetes Benchmark、NIST（米国国立標準技術研究所）のSP 800-190といった公的なベンチマーク・ガイドラインでも体系化されています。自社の対策状況を点検するチェックリストの土台として参照できます。
出典・参考資料（3件）
以下の各セクションで、これらの対策を「なぜ必要か」「どう設定するか」の順に、コマンドやDockerfileの実例とともに解説します。
ビルド（イメージ）の対策
イメージは一度作ると多数の環境で繰り返し使われるため、ビルド段階での設定が、後続のすべての実行環境に影響します。まず押さえたいのは、イメージそのものを安全に作る次の対策です。
最小ベースイメージ（distroless／scratch）とマルチステージビルド
イメージに含まれるパッケージやツールが多いほど、脆弱性の入り込む余地（アタックサーフェス）は広がります。アプリケーションの実行に必要なものだけを残した最小のイメージを選ぶことが、ビルド段階の出発点です。AWSの公式ドキュメントは、パッケージマネージャーやシェルを含まない「distroless」イメージの利用を挙げています。
あるいは、アプリケーションとそのランタイム依存関係のみを含む distroless イメージを使用することもできます。パッケージマネージャーやシェルは含まれません。
出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS
ビルドに使うツールと、実行に必要な成果物を分ける「マルチステージビルド」を使うと、最終イメージからビルドツールやソースコードを除けます。次は、Go製アプリケーションをビルドし、最終段では何も含まないscratchイメージに実行ファイルだけをコピーする例です。
# ビルド用ステージ
FROM golang:1.22 AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server
# 実行用ステージ（最小イメージ）
FROM scratch
COPY --from=build /app/server /server
USER 1000
ENTRYPOINT ["/server"]scratchにはCA証明書が含まれないため、外部とHTTPS通信するアプリケーションでは、ビルドステージからca-certificatesをコピーする必要があります。パッケージを省いたdistrolessのイメージには、必要な証明書があらかじめ含まれています。
Docker公式も、要件に合う最小のベースイメージを選ぶことと、マルチステージビルドで最終イメージを小さく保つことを推奨しています。イメージを小さくすることは、脆弱性の対象を減らすだけでなく、配布やスキャンの速度の面でも利点があります。
出典・参考資料（2件）
非rootユーザーで実行する（DockerfileのUSER）
コンテナは、DockerfileにUSERディレクティブを書かない限り、既定ではroot（管理者）権限で動きます。rootのまま動くコンテナが乗っ取られると、攻撃者はコンテナ内で広い権限を得てしまいます。AWS公式はこの既定を明示したうえで、非rootユーザーでの実行を促しています。
コンテナを実行するときは、非ルートユーザーとして実行してください。デフォルトでは、Dockerfile に USER ディレクティブが含まれていない限り、コンテナは root ユーザーとして実行されます。
出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS
OWASP（Open Worldwide Application Security Project）のDocker Security Cheat Sheetも、非特権ユーザーでコンテナを構成することを「権限昇格攻撃を防ぐ最善の方法」と表現しています。Dockerfileでは、専用ユーザーを作成してUSERで切り替えます。
FROM node:22-slim
WORKDIR /app
COPY --chown=node:node . .
# 依存のインストール（ビルド）はroot権限で実行する
RUN npm ci --omit=dev
# 実行は、既定で用意されている非rootユーザーに切り替える
USER node
CMD ["node", "server.js"]出典・参考資料（2件）
イメージ署名と検証（cosign／Docker Content Trust）
イメージが途中ですり替えられていないか、正規の発行元が作ったものかを確かめるために、イメージへのデジタル署名と、利用時の検証を行います。Docker公式のDocker Content Trust（DCT）は、レジストリとやり取りするデータに署名する仕組みを提供します。
Docker Content Trust (DCT) provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side or runtime verification of the integrity and publisher of specific image tags.
出典：Content trust in Docker｜Docker Docs
DCTはDOCKER_CONTENT_TRUST=1を設定することで有効になります。より新しい仕組みとしては、cosignなどの署名ツールが広く使われており、次のように署名と検証を行います。
# 鍵でイメージに署名する
cosign sign --key cosign.key myregistry/myapp:1.0
# 署名を検証する（検証に通ったイメージだけをデプロイする）
cosign verify --key cosign.pub myregistry/myapp:1.0CNCFのセキュリティ白書も、配布段階で成果物に暗号署名し、完全性と否認防止を担保することの重要性を挙げています。署名したイメージだけをデプロイできるように、後段のCIや実行基盤で検証を組み込むと効果が高まります。
Kubernetesでは、実行基盤側でイメージの署名を検証するAdmission Controller（KyvernoやSigstoreのpolicy-controllerなど）も使えます。これを使うと、署名済みのイメージだけをクラスタで実行するよう強制できます。配布段階の署名と、実行段階の検証をつなぐことで、すり替えられたイメージの実行を入口で止められます。
出典・参考資料（2件）
シークレットをイメージに埋め込まない
パスワード・APIトークン・秘密鍵といったシークレットをDockerfileやイメージ内に書き込むと、イメージを取得できる人なら誰でもそれを読み出せてしまいます。OWASPは、こうした機微な情報をイメージや実行時のコマンドに露出させない運用を推奨しています。
Docker Secrets provide a secure way to store and manage sensitive data such as passwords, tokens, and SSH keys. Using Docker Secrets helps in avoiding the exposure of sensitive data in container images or in runtime commands.
出典：Docker Security Cheat Sheet｜OWASP Cheat Sheet Series
具体的には、ビルド時だけシークレットを渡すBuildKitのビルドシークレット機能や、HashiCorp Vaultなどのシークレット管理ツール、クラウドのシークレットマネージャーを使い、イメージには残さない形にします。
# syntax=docker/dockerfile:1
FROM alpine
# ビルド時だけマウントし、イメージ層には残さない
RUN --mount=type=secret,id=npmtoken cat /run/secrets/npmtoken
# ビルド実行: docker build --secret id=npmtoken,src=./token.txt .Kubernetesで扱う場合は、環境変数として渡すよりも読み取り専用のボリュームにマウントするほうが安全だとOWASPは述べています。
出典・参考資料（2件）
Dockerfileの静的解析（hadolint等）
非rootユーザーの指定や余計なパッケージの排除といったルールは、人手のレビューだけでは漏れます。Dockerfileを静的解析（lint）するツールをビルドの工程に組み込み、ルール違反を自動で検出します。AWS公式は、USERディレクティブの有無をCI／CDでチェックし、見つからなければビルドを失敗させることを勧めています。
CI/CD パイプラインの一部として、Dockerfiles をリントして USER ディレクティブを探し、見つからない場合はビルドを失敗させる必要があります。
出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS
Dockerfile向けの静的解析ツールとしては、hadolintなどが公式ドキュメントでも名前を挙げられています。これらをビルドの一歩目に置くと、以降の対策が守られているかを継続的に確認できます。
出典・参考資料（1件）
- 出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS（リンク）
配布（レジストリ）の対策
作ったイメージは、レジストリで保管・配布する過程で取り違えや改ざんのリスクにさらされます。この段階の対策は、信頼できるイメージだけを使える状態をつくることが目的です。次の4点を項目として押さえます。
同じタグに別の中身のイメージを上書きできる状態だと、攻撃者が侵害したイメージを同じタグで押し込む余地が生まれます。これを防ぐのが「イミュータブル（変更不可）タグ」です。Amazon ECR（AWSのコンテナレジストリ）では、この設定が利用できます。
Amazon ECR では、イミュータブルタグを使用してイメージを設定することができるので、これを使用するようにしてください。これにより、変更または更新されたバージョンの画像が、同一のタグで画像リポジトリにプッシュされるのを防ぐことができます。また、攻撃者が侵害されたバージョンのイメージを同じタグが付いたイメージにプッシュすることを防ぐことができます。
出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS
保存時の暗号化も配布段階の基本です。Amazon ECRにプッシュされたイメージは標準でAWS管理のキーにより暗号化され、独自の鍵で管理したい場合はカスタマーマネージドキー（CMK）による暗号化も選べます。
あわせて、レジストリへのアクセスは必要な利用者・システムだけに絞り、信頼できる発行元のベースイメージだけを使うようにします。CNCFの白書も、安全な配布のためにイメージのバイナリとURLを不変にすることに触れています。
配布段階で押さえる項目は、次のとおりです。
- イミュータブルタグ：同一タグへの上書きを禁止し、イメージの取り違え・すり替えを防ぐ
- 保存時の暗号化：レジストリ保存時にイメージを暗号化する（Amazon ECRは標準で暗号化し、CMKも選択できる）
- アクセス制御：レジストリへのpush／pullを必要な利用者・システムだけに限定する
- 信頼できるイメージの利用：出所の確かな発行元のベースイメージだけを使う
出典・参考資料（2件）
イメージの脆弱性スキャンとCIへの組み込み（シフトレフト）
イメージに含まれる既知の脆弱性は、スキャンして初めて可視化されます。公開されているイメージには、重大な脆弱性が含まれていることが少なくありません。ここでは、スキャンを開発の早い段階に組み込むシフトレフトの考え方まで解説します。
スキャンの対象はイメージ本体だけではありません。アプリケーションのソースコードを調べる静的解析（SAST）、使っているオープンソース依存ライブラリの既知の脆弱性を調べる依存関係スキャン（SCA）、完成したコンテナイメージのスキャンの3種類があります。これらを開発の早い段階から通していくのが、シフトレフトの考え方です。以下ではイメージスキャンを中心に、CIへの組み込み方まで見ていきます。
セキュリティ企業Sysdigの2023年のレポートによると、スキャンされたコンテナイメージの87%に、重大度がHIGHまたはCRITICALの脆弱性が含まれていたとされています。イメージを使う前・使い続ける間、継続的に脆弱性を検査する必要があることを示す数字です。
OWASPは、コンテナスキャンツールをCI／CDパイプラインに組み込むことを、セキュリティ戦略の重要な一部と位置づけています。
Container scanning tools are especially important as part of a successful security strategy. They can detect known vulnerabilities, secrets and misconfigurations in container images and provide a report of the findings with recommendations on how to fix them.
出典：Docker Security Cheat Sheet｜OWASP Cheat Sheet Series
スキャンに使えるオープンソースのツールには、Trivy・Grype・Clairなどがあります。レジストリ側の機能として、Amazon ECRのイメージスキャンのように標準で用意されているものもあります。重要なのは、どのツールを使うかよりも、ビルドやデプロイのどの段階で検査を通すかという「置き場所」です。
たとえばTrivyなら、次のようにイメージを指定して実行します。CIに組み込むときは、重大な脆弱性が見つかったら終了コードでビルドを止める書き方が使えます。
# イメージをスキャンする
trivy image myapp:latest
# high / critical が見つかったら終了コードを1にしてCIを失敗させる
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latestNISTのコンテナセキュリティ指針SP 800-190は、ビルドやデプロイの各段階で基準を満たしたイメージだけを先に進ませる「品質ゲート」を設けることを推奨しています。
Policy-driven enforcement; organizations should be able to create “quality gates” at each stage of the build and deployment process to ensure that only images that meet the organization’s vulnerability and configuration policies are allowed to progress.
出典：NIST SP 800-190 Application Container Security Guide｜NIST
スキャンは一度きりで終わりにはできません。デプロイ済みのイメージにも、後から新たな脆弱性が公表されます。AWS公式は、重大度がHIGHまたはCRITICALのイメージは削除か再構築が必要であり、デプロイ済みのイメージに脆弱性が生じた場合はできるだけ早く交換すべきだとしています。ビルド時のスキャンに加え、稼働中のイメージを継続的に再スキャンする運用をあわせて組みます。
出典・参考資料（4件）
一括ダウンロードする
実行（ランタイム）の対策
ビルド時に安全なイメージを用意しても、実行時に過剰な権限を与えていれば、侵害されたときの影響は大きくなります。コンテナを動かす段階では「与える権限を最小にする」ことが基本の考え方です。
capabilityの削減・特権コンテナの回避（--cap-drop all）
Linuxコンテナには、カーネルの権限を細かく分割した「capability」が既定でいくつも付与されています。アプリケーションが使わない権限は削っておくことで、侵害されたときにできることを狭められます。OWASPは、いったんすべてのcapabilityを削ってから必要なものだけを足す方法を最も安全な構成としています。
The most secure setup is to drop all capabilities
出典：Docker Security Cheat Sheet｜OWASP Cheat Sheet Series--cap-drop alland then add only required ones. Remember not to run containers with the--privilegedflag – this will add ALL Linux kernel capabilities to the container.
# すべての権限を削ってから、必要な CHOWN だけを戻す
docker run --cap-drop all --cap-add CHOWN alpine特権モード（--privileged）での実行は、Linuxカーネルのすべての権限をコンテナに与えるため避けます。AWS公式も、特権としての実行を避けることと、不要なLinux機能をコンテナから削除することを求めています。
あわせて、--security-opt=no-new-privilegesを付けて、実行中に新たな権限を獲得できないようにしておくと、権限昇格のリスクをさらに下げられます。Kubernetesでは、PodのsecurityContextでallowPrivilegeEscalation: falseやcapabilityのdrop: ["ALL"]を指定して同じ効果を得ます。
出典・参考資料（2件）
読み取り専用ルートファイルシステム（--read-only）
コンテナのルートファイルシステムは既定で書き込み可能です。これを読み取り専用にすると、侵入された場合でも不正なファイルの書き込みや改ざんを防ぎやすくなります。AWS公式は、書き込みできる場所を明示的に定義する運用に変わることで、アタックサーフェスが減ると説明しています。
読み取り専用のルートファイルシステムを使用してください。コンテナのルートファイルシステムは、デフォルトでは書き込み可能です。コンテナに RO (読み取り専用) ルートファイルシステムを設定すると、データを保存できる場所を明示的に定義する必要性が生じます。これにより、権限が具体的に付与されない限りコンテナのファイルシステムに書き込みができなくなるため、アタックサーフェスが減少します。
出典：Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス｜AWS
一時ファイルが必要な場合は、書き込み可能な領域だけを--tmpfsで限定的に用意します。Kubernetesでは、コンテナのsecurityContextにreadOnlyRootFilesystem: trueを設定して同じ効果を得ます。
# ルートは読み取り専用にし、/tmp だけ書き込み可能にする
docker run --read-only --tmpfs /tmp alpine出典・参考資料（2件）
seccomp・AppArmorとリソース制限（その他の実行時ハードニング）
コンテナが呼び出せるシステムコールを制限するseccompや、ファイル・ネットワークへのアクセスを制御するAppArmor／SELinuxのプロファイルを適用すると、侵害されたコンテナにできることをさらに狭められます。Dockerでは実行時オプションでプロファイルを指定します。
# seccomp プロファイルを適用する
docker run --security-opt seccomp=/path/to/profile.json myapp
# AppArmor プロファイルを適用する
docker run --security-opt apparmor=my-profile myappあわせて、メモリやCPUの使用量に上限を設けておくと、1つのコンテナの暴走や攻撃による資源の食いつぶし（DoS）が、ホストや他のコンテナへ波及するのを防げます。
# メモリとCPUの上限を設定する
docker run --memory=512m --cpus=1.0 myappまた、Dockerソケット（/var/run/docker.sock）をコンテナにマウントすると、そのコンテナからホスト上のDockerを操作できてしまいます。乗っ取られたときの影響が大きいため、原則としてマウントしないようにします。
出典・参考資料（1件）
- 出典：Docker Security Cheat Sheet｜OWASP Cheat Sheet Series（リンク）
ネットワーク分離・最小化
あるコンテナが侵害されると、同じネットワークにいる隣のコンテナやシステムへの攻撃に使われることがあります。OWASPは、Kubernetesでは既定でPod同士の通信が制限されていない点を指摘しています。
A compromised application can attack neighboring applications. By default, Pods are non-isolated for ingress and egress.
出典：Kubernetes Security Cheat Sheet｜OWASP Cheat Sheet Series
Kubernetesでは、NetworkPolicyを使って、必要な通信だけを許可し、それ以外を遮断する設定にします。NIST SP 800-190も、コンテナからの無制限なネットワークアクセスを制限することを求めています。通信経路を最小化しておくことで、万一の侵害時に被害が横に広がるのを抑えられます。
出典・参考資料（2件）
実行時の監視・異常検知・インシデント対応（Falco等）
ビルド時や設定での対策をすり抜ける攻撃もあるため、コンテナが動いている最中の挙動を監視し、異常を検知する仕組みも必要です。NIST SP 800-190は、コンテナに対応した実行時防御ツールの利用を明確に推奨しています。
Deploy and use a dedicated container security solution capable of preventing, detecting, and responding to threats aimed at containers during runtime. Traditional security solutions, such as intrusion prevention systems (IPSs) and web application firewalls (WAFs), often do not provide suitable protection for containers.
出典：NIST SP 800-190 Application Container Security Guide｜NIST
従来のIPSやWAFだけではコンテナに適した保護になりにくい、という指摘がポイントです。実行時の異常検知に使えるオープンソースにはFalcoなどがあります。
検知だけで終わらせず、異常を見つけた後の手順まであらかじめ決めておきます。具体的には、影響範囲の特定、該当コンテナの隔離・停止、証拠（ログ・スナップショット）の保全といった初動を決めておきます。そのうえで、原因となった脆弱性や設定の修正から再発防止までを、インシデント対応の流れとして用意します。
出典・参考資料（2件）
Kubernetesでの設定例（securityContext／NetworkPolicy）
ここまでの実行時の対策は、Kubernetesではマニフェストで指定します。非root実行・権限昇格の禁止・読み取り専用ファイルシステム・capabilityの削減は、コンテナのsecurityContextにまとめて書けます。
# コンテナの securityContext に指定する
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]Pod間の通信は既定で制限されていないため、NetworkPolicyで「原則すべて拒否し、必要な通信だけ許可する」設定を入れます。次は、名前空間内のすべてのPodへの受信（ingress）を既定で拒否する最小例です。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {} # 名前空間内のすべてのPodが対象
policyTypes:
- Ingress出典・参考資料（1件）
- 出典：Kubernetes Security Cheat Sheet｜OWASP Cheat Sheet Series（リンク）
実行環境別の責任分界（Docker単体／Kubernetes／ECS・EKS・Fargate）
ここまでの対策のうち、どこまでを自社が設定し、どこからを基盤側が担うのかは、コンテナを動かす環境によって変わります。マネージドなサービスを使うほど基盤側の責任範囲は広がりますが、イメージやアプリケーションの設定は常に利用者の責任として残ります。自社の環境ではどこが自分の責任なのかを、ここで整理します。
AWSは、クラウドの責任を「クラウドのセキュリティ（of the cloud）はAWS、クラウド内のセキュリティ（in the cloud）は利用者」という責任共有モデルで整理しています。EKS（AWSのマネージドKubernetes）では、Kubernetesのコントロールプレーンの管理をAWSが担います。
With EKS, AWS is responsible for managing of the EKS managed Kubernetes control plane. (中略) When it comes to infrastructure security, AWS will assume additional responsibilities as you move from self-managed workers, to managed node groups, to Fargate. For example, with Fargate, AWS becomes responsible for securing the underlying instance/runtime used to run your Pods.
出典：Amazon EKS Best Practices Guide – Security｜AWS
自前のサーバーでDockerを動かす場合は、ホストOS・カーネル・デーモンからコンテナまで、すべてが自社の責任です。EKSのマネージドノードグループでは、コントロールプレーンはAWSが管理する一方、ノードのOSを最新のAMIへ更新する責任は利用者に残ります。
FargateではホストやOSのパッチ適用までAWSが担いますが、イメージ・ネットワーク設定・暗号化・IAMのアクセス許可は利用者の責任です。次の表は、代表的な環境ごとの責任分界の目安です。
| 実行環境 | ホスト／カーネル／基盤 | コントロールプレーン／基盤運用 | イメージ・設定・IAM |
|---|---|---|---|
| Docker単体（自前ホスト） | 自社 | 自社 | 自社 |
| Kubernetes（セルフマネージド） | 自社 | 自社 | 自社 |
| EKS（マネージドノードグループ） | ノードOSの更新は自社 | AWS（コントロールプレーン） | 自社 |
| ECS／EKS on Fargate | AWS | AWS | 自社 |
Fargateでは、基盤の管理をAWSに任せられる一方で、できない操作もあります。たとえばAWS Fargate上のAmazon ECSでは、コンテナを特権（privileged）として実行することはサポートされていません。基盤に任せられる範囲とできない操作の両方を把握したうえで、自社が設定すべき対策を見極めます。
出典・参考資料（3件）
全部は一度にできない人のための優先順位と最初の一歩
ここまでの対策をすべて一度に導入するのは現実的ではありません。効果が高く、公式の推奨が強い対策から順に手を付けるのが、無理のない進め方です。ここでは、公式ドキュメントやガイドラインが繰り返し挙げている対策を手がかりに、取りかかる順番の目安を示します。
- 非rootユーザーでの実行と最小権限：OWASPが権限昇格を防ぐ最善の方法と位置づけ、NISTも非特権ユーザーでの実行を挙げる、最も基本の対策です。まずはここから始めます。
- capabilityの削減と特権コンテナの回避：OWASPが「最も安全な構成」として挙げる、すべての権限を削って必要なものだけを戻すアプローチです。
- 脆弱性スキャンのCIへの組み込み：NISTが独立した推奨項目として挙げるスキャンを、ビルドに組み込み、デプロイ後も継続します。
- 実行時の監視・検知：NISTが実行時防御ツールの利用を明確に求めています。ビルド時の対策を補う最後の防御線として整えます。
上記は「まず着手する第一群」です。読み取り専用ファイルシステム、seccomp／AppArmor、ネットワーク分離、イメージ署名も重要な対策で、第一群を入れたうえで、自社の環境やリスクに応じて続けて取り入れる第二群と位置づけると整理がつきます。
まずは非rootでの実行とcapabilityの削減という、設定だけで効果が出る対策から着手し、並行してスキャンをCIに組み込むと、少ない手数でリスクを大きく下げられます。
出典・参考資料（2件）
コンテナのセキュリティ対策をツール・サービスで効率化する
ここまで見てきた対策の多くは、オープンソースのツールやクラウドの標準機能で実装できます。スキャンはTrivyやGrype、Dockerfileの静的解析はhadolint、実行時の監視はFalco、レジストリや暗号化はクラウドの標準機能、といった具合です。
一方で、イメージの検査からクラウド設定の点検、実行時の保護までを別々のツールで運用すると、アラートが分散し、どれから対応すべきかの判断や抜け漏れの管理が重くなりがちです。
OSSや標準機能で運用を回せているチームは、無理にサービスへ移行する必要はありません。一方で、自力での実装・運用が負担になる部分を、脆弱性診断のサービスで一元化する選択肢もあります。ここでは、コンテナイメージの検査を含む複数の診断を1つの画面でまとめて扱えるサービスを例に挙げます。
| サービス | Aikido Security | Trivy | Aqua Security | Sysdig Secure | Prisma Cloud | Wiz |
|---|---|---|---|---|---|---|
| 種別 | 統合型（開発者向けオールインワン） | OSS（スキャナ） | 統合型（CNAPP） | 統合型（CNAPP） | 統合型（CNAPP） | 統合型（CNAPP） |
| 提供形態 | SaaS（クラウド型） | ソフトウェア型（CLI／Docker） | SaaS | SaaS | SaaS／セルフホスト | SaaS（エージェントレス） |
| イメージ脆弱性スキャン | ● | ● | ● | ● | ● | ● |
| クラウド設定（CSPM） | ● | △IaC設定・AWS一部に対応 | ● | ● | ● | ● |
| 実行時（ランタイム）保護 | △Runtime Protection機能あり（契約プランの対象は要確認） | × | ● | ●Falco基盤のランタイム検知に強み | ● | ●Wiz Defend／eBPFセンサー |
| 日本語での窓口・サポート | ●株式会社AndGoが日本語対応 | ×コミュニティ中心（英語） | △国内の現行提供体制は要確認 | ●日本法人・SCSK（販売代理店） | ●日本法人・国内パートナー | ●日本法人・国内パートナー |
| 費用 | 年額サブスク型（無料プランあり） | 無料（OSS） | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| 詳細情報 | 公式資料を見る | 公式サイト | 公式サイト | 公式サイト | 公式サイト | 公式サイト |
※2026年11月時点の各社公式情報をもとに作成。最新の対応状況・料金は各公式サイトでご確認ください。
Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリケーションを1つの管理画面でまとめて検査する脆弱性診断SaaSです。
クラウド向けの機能にはコンテナイメージの検査が含まれ、SCA（依存関係の検査）やSAST（ソースコードの静的解析）、CSPM（クラウド設定の点検）と同じ画面で扱えます。人が診断してレポートを納品する受託型ではなく、自動スキャンのツールを利用する契約形態です。
検出した脆弱性に対して修正案をプルリクエストとして作成する自動修正の機能や、エディター拡張での早期の気づきなど、見つけた後に直すところまでをつなぐ機能を備えます。
アラートの自動トリアージで対応すべきものを絞り込めるため、複数のツールを個別に運用してアラートが分散する状況を避けたいチームに向いています。料金は年額のサブスクリプション型で、無料のDeveloperプランも用意されています（2026年11月時点。最新の料金・対象機能は提供元へ要問い合わせ）。
脆弱性スキャンを開発の早い段階に組み込むシフトレフトが広がる背景には、開発現場でのセキュリティの位置づけ自体の変化があります。この点について、提供元の株式会社AndGoの原氏は独自インタビューで次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。
コンテナに限らず、Webアプリやネットワーク、クラウド設定まで含めて脆弱性診断サービスを診断方法・費用相場・選び方から広く見比べたい場合は、次の記事がサービス選びの出発点になります。
まとめ
コンテナのセキュリティ対策は、イメージを作るビルド段階から、レジストリでの配布、脆弱性スキャン、そして実行時まで、ライフサイクルに沿って領域ごとに押さえることが大切です。ビルド時には最小イメージ・非rootユーザー・署名・シークレットの分離を、実行時にはcapabilityの削減・特権回避・読み取り専用ファイルシステム・監視を、それぞれ公式の推奨に沿って設定します。
すべてを一度に導入する必要はありません。非rootでの実行やcapabilityの削減など、設定だけで効果が出る対策から始め、スキャンをCIに組み込みながら、自社の実行環境での責任範囲に合わせて段階的に広げていくのが現実的です。自力での運用が重くなる部分は、脆弱性診断サービスの活用も選択肢になります。
一括ダウンロードする
よくある質問（FAQ）
Q. コンテナセキュリティとは何ですか？
コンテナセキュリティとは、コンテナイメージを作るビルドから、レジストリでの配布、実行（ランタイム）まで、コンテナのライフサイクルの各段階でリスクを下げる取り組みの総称です。ネットワークの境界を守る従来型のセキュリティだけでは、イメージに含まれる脆弱性や過剰な権限といったコンテナ特有のリスクを防ぎきれないため、段階ごとに対策を重ねる考え方が必要になります。
Q. コンテナセキュリティ対策は何から始めればよいですか？
コンテナセキュリティは、非rootユーザーでの実行とcapabilityの削減という、設定だけで効果が出る対策から始めるのが現実的です。いずれも公式ドキュメントが繰り返し推奨する基本対策で、Dockerfileや実行時オプションの変更だけで導入できます。並行して脆弱性スキャンをCI／CDに組み込むと、少ない手数でリスクを大きく下げられます。
Q. コンテナセキュリティ対策はオープンソースだけで十分ですか？
コンテナセキュリティの主要な対策は、Trivy（スキャン）・hadolint（静的解析）・Falco（実行時監視）といったオープンソースと、クラウドの標準機能だけでも実装できます。
一方で、イメージ検査・クラウド設定の点検・実行時保護を別々のツールで運用すると、アラートが分散し、優先順位づけや抜け漏れの管理が重くなりがちです。運用まで含めて回したい場合は、複数の診断を1つの画面でまとめられる脆弱性診断サービスも選択肢になります。
Q. コンテナの脆弱性スキャンはいつ・どのツールで行えばよいですか？
コンテナの脆弱性スキャンは、ビルド時にCI／CDパイプラインへ組み込み（シフトレフト）、デプロイ後も継続的に再スキャンするのが基本です。デプロイ済みのイメージにも後から新たな脆弱性が公表されるため、一度きりでは不十分です。
ツールはTrivy・Grype・Clairなどのオープンソースのほか、Amazon ECRのイメージスキャンのようなレジストリの標準機能も使えます。どのツールを使うかよりも、どの段階で検査を通すかという置き場所が重要です。
Q. ECS・EKS・Fargateでは、コンテナセキュリティのどこまでが自社の責任ですか？
マネージド基盤を使うほど基盤側の責任範囲は広がりますが、イメージの中身・コンテナの設定・IAMのアクセス許可は、どの環境でも常に利用者の責任として残ります。
EKSのマネージドノードグループではコントロールプレーンの管理をAWSが担う一方、ノードOSの更新は利用者に残ります。Fargateではホストやそのパッチ適用までAWSが担いますが、特権コンテナの実行はサポートされないなど、基盤に任せられる範囲とできない操作の両方を把握しておく必要があります。
Q. Docker単体とKubernetesで、コンテナセキュリティ対策は違いますか？
イメージの最小化・非root実行・capability削減・読み取り専用ファイルシステムといった基本対策は、Docker単体でもKubernetesでも共通です。KubernetesではこれらをコンテナのsecurityContextで指定するほか、既定で制限されていないPod間の通信をNetworkPolicyで絞るなど、クラスタ／オーケストレーター層の対策が加わります。
Q. 非rootユーザーでの実行や読み取り専用ファイルシステムは必須ですか？
法律上の義務ではありませんが、いずれもAWSやOWASPの公式ドキュメントが推奨する基本対策で、原則として設定すべきものです。非rootでの実行は権限昇格攻撃を防ぐ最善の方法とされ、読み取り専用のルートファイルシステムはアタックサーフェスを減らします。一時ファイルの書き込みが必要な場合は、--tmpfsで書き込み可能な領域だけを限定的に用意すれば両立できます。
Q. 特権コンテナ（–privileged）を使ってはいけないのですか？
特権コンテナはLinuxカーネルのすべての権限をコンテナに与えるため、本番環境では原則として避けるべきです。権限が必要な場合も、いったんすべてのcapabilityを削ってから必要なものだけを戻す構成が推奨されます。AWS Fargate上のAmazon ECSでは、特権としての実行自体がサポートされていません。
Q. スキャンでコンテナイメージの脆弱性が見つかったらどうすればよいですか？
重大度がHIGHまたはCRITICALのイメージは、パッチ適用による修正か再構築が必要で、すでにデプロイ済みであればできるだけ早く差し替えることが推奨されます。AWS公式もこの対応を求めています。だからこそ、ビルド時のスキャンに加えて、稼働中のイメージを継続的に再スキャンする運用をあわせて組む必要があります。
Q. すでに本番で動いているコンテナにも、後から対策を適用できますか？
後からでも適用できます。非rootユーザー化やシークレットの分離はDockerfileの修正と再ビルドで、capabilityの削減や読み取り専用ファイルシステムは実行時オプションやKubernetesのマニフェストの変更で導入できます。一度にすべてを変えるのではなく、優先順位の高い対策から段階的に適用し、再デプロイしていくのが現実的です。
Q. CISベンチマークやNIST SP 800-190とは何ですか？
CIS Docker／Kubernetes BenchmarkやNIST SP 800-190は、コンテナセキュリティで実施すべき対策とその推奨水準を体系的にまとめた、公的なガイドラインです。本記事で紹介した対策の多くも、これらや各種公式ドキュメントの推奨に沿っています。自社の対策状況を点検するチェックリストや、社内のレビュー・説明の根拠として参照すると役立ちます。
Q. コンテナセキュリティ対策は、小規模なチームでもすべて必要ですか？
規模にかかわらず、インターネットに公開するコンテナには最低限のセキュリティ対策が必要です。ただし、本記事のすべてを一度に導入する必要はありません。まず非root実行・capabilityの削減・脆弱性スキャンといった、効果が高く設定だけで済む対策から着手し、自社の実行環境での責任範囲に合わせて段階的に広げるのが、小規模チームにも無理のない進め方です。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナを含む脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。検査できる対象や診断方式、料金を横断で比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
