自社のWebサービスやアプリをDockerコンテナで動かすようになると、「このまま本番に出して大丈夫なのか」という不安がつきまといます。セキュリティの専任担当がいない開発・インフラのチームでは、何がどこまで危ないのか、どこから手をつければよいのかが見えにくいものです。
Dockerのリスクは、イメージ・ホスト（デーモン）・レジストリ・ネットワーク・実行時という複数の層に分かれています。層ごとに「なぜ危ないのか」と「最低限何をすればよいのか」を押さえれば、専門家でなくても初歩的な穴は着実に塞げます。
本記事では、Dockerコンテナセキュリティの考え方と具体的な対策を、層ごとに整理します。あわせて、自前の対策だけでは届きにくい範囲と、コンテナに対応した脆弱性診断サービスで補う方法も解説します。
目次
一括ダウンロードする
Dockerコンテナセキュリティとは？なぜ危ないのか
はじめに、Dockerコンテナがなぜセキュリティ上の注意を要するのか、その仕組みから整理します。危なさの根っこを押さえると、以降の対策が「なぜ必要か」でつながって理解しやすくなります。
コンテナが仮想マシンと違って危ない理由（ホストカーネルの共有）
Dockerコンテナは、仮想マシン（VM）のように独立したOSを持つのではなく、ホストOSのカーネルを複数のコンテナで共有して動きます。この構造上、コンテナ同士やホストとの分離は、ハイパーバイザーでハードウェアレベルに区切るVMほど強固ではありません。
米国国立標準技術研究所（NIST）のコンテナセキュリティガイド（SP 800-190）も、この分離の弱さを次のように指摘しています。
While containers provide a strong degree of isolation, they do not offer as clear and concrete of a security boundary as a VM. Because containers share the same kernel and can be run with varying capabilities and privileges on a host, the degree of segmentation between them is far less than that provided to VMs by a hypervisor.
（コンテナは高い分離性を備えるものの、VMほど明確で具体的なセキュリティ境界は提供しない。コンテナは同じカーネルを共有し、ホスト上でさまざまな権限・ケイパビリティで実行されうるため、コンテナ間の分離の度合いはハイパーバイザーがVMに与える分離よりはるかに弱い。）
出典：NIST SP 800-190「Application Container Security Guide」（米国国立標準技術研究所）
この分離の弱さがあるため、1つのカーネルの脆弱性や、コンテナに与えすぎた権限が、ほかのコンテナやホスト全体に波及しかねません。だからこそ、イメージの中身・コンテナに渡す権限・稼働中の挙動を、それぞれ意識して守る必要があります。
具体的な侵害の経路はいくつか知られています。たとえば、脆弱性を突いてコンテナからホストへ抜け出す「コンテナエスケープ」、操作用ソケット（docker.sock）の露出を足がかりにした乗っ取り、公開したAPI・ポートからの侵入とそれを使った不正なマイニングなどです。こうした経路をふさぐのが、以降の各層の対策です。
Dockerのリスクは5つの層にある
Dockerのセキュリティ対策は、守る対象を層で分けると見通しがよくなります。本記事では以下の5つの層に整理し、次章以降の対策もこの順番で解説します。
- イメージ: コンテナのもとになるイメージに含まれる脆弱性・余計なパッケージ・埋め込まれた秘密情報
- ホスト・デーモン: コンテナを動かすDockerデーモンやホストに与えられた権限、デーモンへの接続経路
- レジストリ: イメージを取得・配布する場所の信頼性と、すり替え（改ざん）への備え
- ネットワーク: コンテナが公開するポートやAPIの露出範囲、コンテナ間の通信の分離
- 実行時: 稼働し続けるコンテナで起きる想定外の挙動や、時間とともにずれていく設定
「作る時」に固めるのがイメージ・ホスト・レジストリ・ネットワークの対策、「動かし続ける間」に守るのが実行時の対策、という分け方もできます。両方をそろえて初めて、一通りの備えになります。
Dockerコンテナセキュリティ対策の全体像｜何から始めるか
ここでは、層ごとの代表的な対策を一覧にまとめます。「何をするか」「なぜ必要か」「使える標準機能・コマンド」を並べているので、自社でまだ手をつけていない対策を見つける地図として使ってください。
| 対策 | ベースイメージの最小化 | 非rootでの実行 | イメージの脆弱性スキャン | シークレットを埋め込まない | イメージの署名・検証 | デーモン・ソケットの保護 | 権限・リソースの制限 | ホストからの分離強化 | レジストリ・ネットワーク | 実行時の監視 |
|---|---|---|---|---|---|---|---|---|---|---|
| 何をするか | slimやdistrolessなど最小構成を選び、タグはdigestで固定する | コンテナ内の実行ユーザーを一般ユーザーにする | イメージに含まれる既知の脆弱性を検出・修正する | 認証情報やトークンをイメージ層に残さない | 配布するイメージの出所と改ざんの有無を検証する | docker.sockを露出せず、リモート接続はSSH/TLSで守る | ケイパビリティを絞り、読み取り専用化、CPU/メモリ上限を設定 | コンテナ内のrootをホストの非特権ユーザーに再マッピングする | 信頼できるレジストリを使い、不要なポート・APIを公開しない | 稼働中コンテナの異常な挙動を検知してアラートする |
| なぜ必要か | 攻撃対象になるパッケージを減らし、イメージの差し替えを防ぐ | 侵入されても権限昇格を起こしにくくする | 既知のCVEを本番に持ち込まない | 漏えいすると不正アクセスに直結する | すり替え（中間者攻撃・供給網攻撃）を防ぐ | デーモンの権限はホストのroot相当のため | 侵害時の影響範囲とリソース枯渇を抑える | コンテナから抜け出されてもホストで無権限にする | 不正なイメージの混入や外部からの露出を防ぐ | 作った後に起きる攻撃や設定のずれに対応する |
| 使える標準機能・コマンド | FROMで最小イメージ、@sha256:… でのピン留め | DockerfileのUSER命令 | docker scout cves、Trivy（OSS） | BuildKitの–secret（RUN –mount=type=secret） | Cosign／Sigstore | SSH接続、TLS（tlsverify） | –cap-drop、–read-only、–memory/–cpus | user namespace（–userns-remap） | プライベート／認証済みレジストリ、-pでの公開範囲の限定 | Falco（OSS） |
すべてを同時に完璧にする必要はありません。次の順で広げていくと、無理なく守りを厚くできます。
- まず着手: イメージの脆弱性スキャンと非rootでの実行（既知の脆弱性を本番に持ち込まず、侵入されても権限昇格を起こしにくくする）
- あわせて: 公開ポートの絞り込み（不要なポートを外部に出さない）
- 次に: ホスト・デーモンの保護（docker.sockの露出回避・権限とリソースの制限）と、信頼できるレジストリの利用
- 最後に: 実行時の監視
少なくとも1と2が揃えば、本番運用での初歩的なリスクはひとまず塞げます。そのうえで3・4まで広げると、より厚い備えになります。
一括ダウンロードする
イメージを守る対策
ここからは、「作る時」にイメージを堅くする対策を見ていきます。コンテナのもとになるイメージは、一度作ると何度も使い回されるため、ここでの対策が全体の土台になります。
ベースイメージを最小化する
イメージに含まれるパッケージが多いほど、脆弱性を抱える確率も上がります。Docker公式のビルドのベストプラクティスでも、要件に合う最小限のベースイメージを選ぶことが推奨されています。用途に不要なシェルやツールを含まないslimイメージやdistrolessイメージが候補になります。
あわせて注意したいのがタグの扱いです。公式ドキュメントは「イメージのタグは可変であり、publisherがタグの指す先を別のイメージへ更新できる」と説明しています。供給網の完全性を厳密に保つなら、タグではなく特定のdigest（@sha256:...）でイメージをピン留めします。latestのような可変タグに頼り切らない、という考え方です。
出典・参考資料（1件）
非rootユーザーで実行する
コンテナ内のプロセスを管理者（root）で動かすと、万一侵入された際に権限を奪われたときの影響が大きくなります。DockerfileにUSER命令を書き、一般ユーザーで実行するのが基本です。公式のDockerfileリファレンスはUSER命令を次のように定義しています。
The
USERinstruction sets the user name (or UID) and optionally the user group (or GID) to use as the default user and group for the remainder of the current stage.（
出典：Dockerfile reference「USER」｜Docker DocsUSER命令は、以降のステージで既定として使うユーザー名またはUIDと、任意でユーザーグループまたはGIDを設定する。）
# 一般ユーザーを作成し、USER命令で切り替える例
RUN useradd --create-home appuser
USER appuserイメージの脆弱性をスキャンする
ビルドしたイメージに既知の脆弱性（CVE）が含まれていないかは、ツールで検査できます。現在のDocker公式のコマンドはDocker Scoutで、docker scout cvesでイメージ内のパッケージと脆弱性のレポートを出力します。
# 直近にビルドしたイメージの脆弱性を解析する
$ docker scout cvesかつて使われていたdocker scanコマンドは、すでに削除されています。公式プラグインのリリースノートにも「The docker scan command has been removed.」と明記されているため、現役のコマンドとしては使わないよう注意してください。
Docker Scoutのほかに、サードパーティのオープンソースツールであるTrivyなども、イメージスキャンの選択肢になります。
出典・参考資料（2件）
シークレットをイメージに埋め込まない
APIキーやパスワードなどの秘密情報を、Dockerfileのビルド引数（ARG）や環境変数（ENV）で渡すと、最終イメージの層に残ってしまいます。Docker公式も「ビルド引数や環境変数はシークレットの受け渡しには適さない」としています。
代わりに、BuildKitのシークレット機能を使えば、秘密情報はそのRUN命令の実行中だけ/run/secrets/にマウントされ、イメージ層には残りません。
# ビルド時にシークレットを渡す
$ docker build --secret id=aws,src=$HOME/.aws/credentials .
# Dockerfile側（RUN実行中だけ /run/secrets/aws にマウントされる）
RUN --mount=type=secret,id=aws \
AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \
aws s3 cp ...加えて、マルチステージビルドでビルド用の中間成果物を最終イメージに持ち込まない、COPY . .のような再帰コピーで不要なファイルや認証情報をまとめて取り込まない、といった配慮も有効です。
出典・参考資料（1件）
イメージに署名し検証する
配布の途中でイメージがすり替えられていないかは、署名と検証で確かめられます。現在の標準的な方法は、CNCF（Cloud Native Computing Foundation）のプロジェクトであるSigstoreのCosignです。鍵ペアを使う署名のほか、OIDC（外部のIDプロバイダによる認証）と連携したキーレス署名にも対応しています。
# 署名（キーレス）
$ cosign sign $IMAGE
# 検証（キーレス・OIDC）
$ cosign verify <image URI> \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.comかつて使われていたDocker Content Trust（DCT）とNotary v1は、公式に終了が告知されています。Docker公式ページには「Docker Content Trust (DCT) is being retired.」と明記され、Notary v1のサービス（notary.docker.io）も2026年12月8日に停止するとされています。
これから署名の仕組みを導入するなら、DCTではなく現行のCosign／Sigstoreを選ぶのが確実です。
出典・参考資料（2件）
ホスト・デーモンを守る対策
続いて、コンテナを動かすホストとDockerデーモンの守り方です。コンテナそのものよりも、コンテナを動かす土台のほうが、奪われたときの影響は大きくなります。
Dockerデーモン・ソケット（docker.sock）を保護する
Dockerデーモンは、デーモンを一般ユーザー権限で動かすrootless modeを選ばない限り、root権限で動きます。そのため、デーモンや操作用のソケット（docker.sock）を握られると、実質的にホストのroot権限を渡すのと同じことになります。コンテナにdocker.sockを安易にマウントしない、という点はとくに重要です。
リモートからデーモンを操作する場合、Docker公式はSSH経由での接続を推奨しています。どうしてもネットワーク越しにHTTPで届かせる必要があるときは、TLS（tlsverifyとCA署名のクライアント証明書）で保護します。公式も、クライアント鍵について次のように警告しています。
anyone with the keys can give any instructions to your Docker daemon（鍵を持つ者は誰でも、Dockerデーモンに任意の命令を与えられる）
出典：Protect the Docker daemon socket｜Docker Docs
ケイパビリティの削減・読み取り専用・リソース制限で権限を絞る
コンテナに与える権限は、必要な分だけに絞るのが原則です。Linuxのケイパビリティ（カーネルの特権を細かく分けた権限）は--cap-dropで削り、不要なものを足さないようにします。一般的なプラクティスとしては、いったんすべて落として必要なものだけ--cap-addで足す方法が知られています。
あわせて、ファイルシステムを--read-onlyで読み取り専用にし、--memoryや--cpusでリソースの上限を設けます。リソース制限は、1つのコンテナが暴走してホスト全体のリソースを食いつぶす事態（DoS）を防ぎます。
# 権限とリソースを絞って実行する例
$ docker run \
--cap-drop=ALL --cap-add=NET_BIND_SERVICE \
--read-only \
--memory=512m --cpus=".5" \
myapp:1.0なお、--privilegedはこれらの制限を取り払ってしまうため、原則として使わないようにします。
加えて、Dockerはコンテナに既定でseccompプロファイル（許可するシステムコールを制限する仕組み）とAppArmor（Linuxのアクセス制御機構）のプロファイルを適用します。これらを無効化せず、さらに--security-opt no-new-privilegesで実行中の権限昇格を防ぐと、守りがより固くなります。
デーモン自体を非rootで動かすrootless modeも、ホスト側に渡る権限を下げる選択肢です。
出典・参考資料（2件）
user namespaceでホストからの分離を強める
user namespace（ユーザー名前空間）を使うと、コンテナ内のrootを、ホスト上では高番号の非特権ユーザーに再マッピングできます。万一コンテナから抜け出されても、ホスト上では権限を持たない状態にできるため、分離がさらに強まります。
Docker公式も、user namespaceの再マッピングについて「This means the process has no privileges on the host system at all.（これにより、そのプロセスはホストシステム上でまったく権限を持たない）」と説明しています。有効化はデーモンの設定（daemon.json）で行います。
出典・参考資料（1件）
一括ダウンロードする
レジストリとネットワークを守る対策
ここでは、イメージの取得元であるレジストリと、コンテナの外部への露出について整理します。入り口と出口をふさぐ対策です。
信頼できるレジストリ・イメージソースを使う
イメージの出所が信頼できなければ、どれだけ中身を固めても意味が薄れます。公式イメージや認証済みのイメージを使い、自社で管理するイメージはプライベートレジストリや認証済みのレジストリに置くのが基本です。取得したイメージは、前章のスキャンと署名検証で改ざんの有無を確かめます。
こうしたレジストリやネットワークの設定は、業界標準の設定指針であるCIS Docker Benchmarkが体系的な基準を示しています。自社の設定を点検する際の参照にすると、抜けを見つけやすくなります。
ネットワークを分離しAPI・ポートの露出を絞る
コンテナが外部に公開するポートは、必要なものだけに絞ります。-p 127.0.0.1:8080:8080のようにバインド先を限定すればホスト内からのみ到達でき、外部公開が不要なポートは-pで出さないようにします。デーモンのAPIを無防備にネットワークへ公開すると、前述のとおりホストの乗っ取りに直結します。
コンテナ間の通信も、既定のbridgeネットワークに同居させず、docker network createで用途ごとにユーザー定義ネットワークを分けると、1つのコンテナの侵害が横に広がりにくくなります。
# 用途ごとにネットワークを分け、必要なコンテナだけを接続する
$ docker network create app-net
$ docker run --network app-net myapp:1.0
# 公開ポートはバインド先を絞る（ホスト内からのみ到達可能）
$ docker run -p 127.0.0.1:8080:8080 myapp:1.0Docker公式も、デーモンを操作できるのは信頼できるユーザーだけに限ること、APIをHTTPで届かせる場合は証明書で保護することを求めています。コンテナ間の通信も、用途ごとにネットワークを分けておくと、1つのコンテナの侵害が横に広がりにくくなります。
出典・参考資料（2件）
実行時（運用中）に守る・異常を検知する
ここまでは「作る時」の対策でした。ここからは、コンテナを「動かし続ける間」の守り方を見ていきます。
なぜ「作る時」だけでなく「動かし続ける間」も守る必要があるのか
イメージを固めても、本番で動き続けるコンテナには新たな脆弱性が見つかったり、設定が少しずつ当初の想定からずれたりします。コンテナは生成と破棄が頻繁で変化が速いため、従来型の防御では追いつきにくいのが実情です。NISTも次のように、コンテナ専用の実行時防御を勧めています。
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.
（実行時のコンテナを狙う脅威を、予防・検知・対応できる専用のコンテナセキュリティソリューションを導入・活用すること。侵入防止システム（IPS）やWAFといった従来型のセキュリティでは、コンテナに適した保護を提供できないことが多い。）
出典：NIST SP 800-190「Application Container Security Guide」（米国国立標準技術研究所）
ランタイム監視・ログ監査・侵入検知（Falco）
実行時の監視でよく使われるのが、CNCFのオープンソースであるFalcoです。Falcoは、Linuxカーネルのシステムコールを実行時に解析し、ルールに反する挙動をリアルタイムに検知してアラートします。公式も、ホスト・コンテナ・Kubernetesをまたいで実行時のセキュリティを提供し、異常な挙動や潜在的な脅威をリアルタイムに検知・通知するツールだと説明しています。
たとえば、コンテナ内での予期しない権限昇格、機密ディレクトリへの書き込み、想定外の外部通信などを、ルールにもとづいて検知できます。「作った後」に起きる異常に気づける状態を整えておくことが大切です。
あわせて、コンテナの標準出力・標準エラーはDockerのログドライバ（json-fileやjournald、集約基盤へ転送するfluentdなど）で収集し、操作やアクセスの記録を残します。ログを集約しておくと、Falcoなどの検知と突き合わせて、異常の予兆や影響範囲を後から追えます。
出典・参考資料（1件）
どこまで自前でやり、どこから外部の脆弱性診断に任せるか
ここからは、ここまでの対策を自前でどこまでやり、どこから外部の力を借りるとよいかを整理します。手段の多さに圧倒されず、現実的な線引きを考えるための章です。
自前のDocker対策で届く範囲と、届きにくい範囲
本記事で紹介した対策は、Dockerの標準機能やオープンソースツールで実施できるものが中心です。イメージの最小化・非root化・スキャン・署名、デーモンの保護、リソース制限までは、開発・インフラのチームが自前で着実に進められます。
一方で、届きにくい範囲もあります。コンテナ単体だけでなく、その上で動くWebアプリケーションそのものの脆弱性、クラウドの設定ミス、依存ライブラリやソースコードの問題まで含めて、継続的に・網羅的に洗い出すのは、個別ツールの組み合わせだけでは手が回りにくくなります。本番運用後も安全を保ち続けたい、第三者の視点で抜けを確かめたい、という段階では、コンテナに対応した脆弱性診断サービスで補うのが現実的です。
どの脆弱性診断サービスが自社に合うか、診断方法の種類・費用相場・選び方まで含めて比較したい方は、以下の記事でまとめて解説しています。無料で使えるツールも取り上げているので、外部サービスの検討を始める際の全体像をつかめます。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
自前のOSSツールと統合型の脆弱性診断サービスのカバー範囲
自前で使えるオープンソースツールと、イメージから稼働中のアプリ・クラウド設定までを一括で検査できる脆弱性診断サービスを比べると、カバーする範囲の違いが見えてきます。
イメージの脆弱性スキャンや実行時の検知は、docker scout cvesやTrivy、Falcoといった無料のツールでも十分に実施できます。違いが出やすいのは、ソースコードからクラウド設定・稼働中のWebアプリまでを1つの画面でまとめて検査・管理できるか（統合管理）という点です。
| 比較項目 | 自前のOSSツール （組み合わせ運用） | Aikido Security |
|---|---|---|
| コンテナイメージ検査 | ●docker scout cves・Trivyで対応 | ● |
| ソースコード・依存ライブラリ（SAST・SCA） | △別途、専用ツールの追加が必要 | ● |
| クラウド設定（CSPM） | △別分野のツールが別途必要 | ● |
| 稼働中Webアプリ（DAST） | △別途、専用ツールの追加が必要 | ● |
| 実行時の監視・保護（Runtime） | ●Falcoで監視・検知 | ● |
| 統合管理（1画面で一元把握） | ×ツールごとに個別運用 | ◎1つの管理画面で一元化 |
| 提供形態 | 各ツールを自前で導入・運用 | SaaS（月額サブスク型） |
Aikido Security（株式会社AndGo）
Aikido Securityは、コンテナイメージの検査から稼働中アプリ・クラウド設定の脆弱性検査までを1つにまとめた、オールインワンの脆弱性診断SaaSです。
コンテナイメージのスキャンに加え、ソースコード（SAST）・依存ライブラリ（SCA）・クラウド設定（CSPM）・稼働中のWebアプリ（DAST）、さらに実行時の保護（Runtime Protection）まで、複数の検査を1つの画面で扱えます。
個別のオープンソースツールを組み合わせて運用する場合に課題になりがちな「どこに何の脆弱性が残っているかの一元把握」を、まとめて行いたいチームに向いています。本記事で解説したイメージスキャンや実行時監視を、自前のツール運用から統合的なサービスへ移したい場合の選択肢になります。
実際に使える機能は契約するプランによって変わります。自社のコンテナ環境にどこまで対応できるかは、資料や問い合わせで確認するのが確実です。
個別のツールを組み合わせたときに、開発・運用の現場で何が起きやすいのか。同サービスを提供する株式会社AndGoの原氏は、次のように話しています。
まとめ
Dockerコンテナのセキュリティは、イメージ・ホスト（デーモン）・レジストリ・ネットワーク・実行時という層ごとに、「なぜ危ないか」と「最低限何をするか」を押さえることが出発点です。
- 着手順を決める: まずは効果の高いイメージの脆弱性スキャンと非root化から始め、ホスト・デーモンの保護、実行時の監視へと広げる
- 最新の方法を使う: 署名検証はCosign／Sigstore、スキャンは
docker scout cvesを使い、終了したDCTや削除されたdocker scanに頼らない - 自前の限界を補う: 稼働中アプリ・クラウド設定まで含めた継続的な検査は、コンテナ対応の脆弱性診断サービスで補う
「作る時」と「動かし続ける間」の両方をそろえ、自前で届く範囲と外部に任せる範囲を見極めることが、現実的で続けられるコンテナセキュリティの土台になります。まずは着手しやすい対策から、自社のコンテナ環境に取り入れてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. Dockerコンテナセキュリティとは何ですか？
A. Dockerコンテナセキュリティとは、Dockerで動かすコンテナを、イメージ・ホスト（デーモン）・レジストリ・ネットワーク・実行時という複数の層にわたって、脆弱性や設定ミス・不正アクセスから守る取り組みのことです。コンテナはホストOSのカーネルを共有する仕組みのため、VMほど強い分離がありません。そのため、どれか1つの対策だけでなく、各層でそれぞれ備えることが前提になります。
Q. Dockerコンテナは仮想マシン（VM）より危ないのですか？
A. Dockerコンテナは、VMほど明確なセキュリティ境界を持たないぶん、分離の弱さを意識した対策が必要になります。VMがハイパーバイザーでハードウェアレベルに区切られるのに対し、コンテナはホストのカーネルを共有するため、1つのカーネルの脆弱性や与えすぎた権限が、ほかのコンテナやホスト全体に波及しうるからです。
これはDockerが危険で使うべきでない、という意味ではありません。構造に合わせて権限やイメージ・実行時の挙動を守れば、本番運用に十分使える技術です。
Q. Dockerのセキュリティ対策は何から始めればいいですか？
A. Dockerのセキュリティ対策は、効果が高く着手しやすい「イメージの脆弱性スキャン」と「非rootでの実行」から始めるのが現実的です。この2つで既知の脆弱性を本番に持ち込まず、侵入されても権限昇格を起こしにくい状態をまず作れます。
そのうえで、ホスト・デーモンの保護（docker.sockの露出を避ける、権限・リソースの制限）、最後に実行時の監視へと順に広げると、無理なく守りを厚くできます。すべてを同時に完璧にする必要はありません。
Q. 無料でできるDockerのセキュリティ対策はありますか？
A. Dockerのセキュリティ対策の多くは、Dockerの標準機能やオープンソースツールだけで無料で始められます。非rootでの実行（USER命令）、権限・リソースの制限（--cap-drop・--read-only）、脆弱性スキャン（docker scout cves・Trivy）、署名・検証（Cosign）、実行時監視（Falco）は、追加費用なく導入できます。
ただし、これら無料ツールの組み合わせだけで、稼働中のWebアプリやクラウド設定まで含めて継続的に・網羅的にカバーしきるのは難しい点には留意が必要です。
Q. Dockerイメージの脆弱性スキャンにはどのツールを使えばいいですか？
A. Dockerイメージの脆弱性スキャンには、Docker公式のdocker scout cvesか、オープンソースのTrivyが基本的な選択肢になります。どちらもイメージに含まれるパッケージと既知の脆弱性（CVE）を検出できます。なお、かつて使われていたdocker scanコマンドはすでに削除されているため、現役のコマンドとしては使わないよう注意してください。
1つのツールですべての脆弱性を見つけられるわけではないので、ビルドのたびにスキャンを回し、修正を継続する運用が大切です。
Q. 本番環境と開発環境で、Dockerのセキュリティ対策のレベルを変えてもよいですか？
A. すべてのイメージやコンテナに、一律で同じ強度の対策を課す必要はありません。外部に公開する本番環境のイメージ・コンテナには、スキャン・署名検証・実行時の監視まで含めて厳しく適用し、社内限定で使う開発用は優先度を下げる、といったメリハリが現実的です。
一方で、開発環境の緩い設定や埋め込んだ秘密情報がそのまま本番へ流れ込まないよう、イメージの作り分けと、本番へ出す前のスキャンだけは欠かさないようにします。
Q. 自前のDocker対策だけで十分ですか？外部の脆弱性診断は必要ですか？
A. 自前の対策で初歩的な穴は着実に塞げますが、それだけで100%安全になるわけではありません。イメージの最小化・非root化・スキャン・署名、デーモンの保護、リソース制限までは開発・インフラのチームが自前で進められます。
一方で、コンテナの上で動くWebアプリそのものの脆弱性、クラウドの設定ミス、依存ライブラリやソースコードの問題まで、継続的に・網羅的に洗い出すのは個別ツールの組み合わせだけでは手が回りにくくなります。本番運用後も安全を保ち続けたい、第三者の視点で抜けを確かめたいという段階では、コンテナに対応した脆弱性診断サービスで補うのが現実的です。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナやWebアプリに対応した脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。検査できる対象の範囲・料金・サポート体制などを、まとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
