Dockerセキュリティの基礎

JPKODA 編集部 May 12, 2026

コンテナ化アプリケーションをデプロイするすべての人にとって、Dockerのセキュリティを理解することは最優先事項です。コンテナはホストマシンのOSカーネルを共有しているため、1つのコンテナの脆弱性がシステム全体を危険にさらす可能性があります。さらに、不適切なコンフィギュレーションのDockerfileや安全でないイメージソースを使用すると、初期段階からアプリケーションに脆弱性を組み込んでしまう恐れがあります。

本章では、Dockerに関連する一般的なセキュリティリスクを深く掘り下げ、これらのリスクを軽減するためのベストプラクティスを実装するための基礎を築きます。Dockerデーモン、コンテナのコンフィギュレーション、イメージソースに関連する脆弱性を調査し、安全なDockerデプロイメントを構築するためのアプローチを学びます。

1. 一般的なDockerのセキュリティリスク

Dockerのセキュリティリスクは、主にいくつかの側面から発生します：Dockerデーモン（Daemon）、コンテナのコンフィギュレーション、および使用されるイメージです。これらのリスクを理解することは、安全なコンテナ化アプリケーションを構築するための鍵となります。

1.1 Dockerデーモンの脆弱性

すべてのコンテナを管理するDockerデーモン（dockerd）は、通常 root 権限で実行されます。これが侵害された場合、攻撃者はホストマシンシステムに対する完全なコントロールを取得する可能性があります。

リスク: Dockerデーモンの既知の脆弱性のエクスプロイト（悪用）。
例: 古いバージョンのDockerには、攻撃者がコンテナから「エスケープ」してホストマシンの root アクセス権を取得できる既知の脆弱性が存在します。ある仮想のシナリオとして、プロダクションサーバー上でパッチが適用されていないDockerデーモンが実行されており、攻撃者が公開されているエクスプロイトコードを利用してサーバーの完全な制御を奪うケースが考えられます。
防御策:

Dockerデーモンを最新のセキュリティパッチで常にアップデートしておくこと。
Dockerデーモンのコンフィギュレーションを定期的に監査すること（例：Docker APIをパブリックネットワークに公開しない）。

実際の事例: 2019年、Dockerが使用するコンテナランタイムである runc において、深刻なコンテナエスケープの脆弱性（CVE-2019-5736）が発見されました。runc とDockerをアップデートすることが、このクリティカルな問題を解決する唯一の手段でした。

1.2 コンテナのコンフィギュレーション問題

不適切なコンフィギュレーションのコンテナは、セキュリティの脆弱性を生み出します。これらの設定には、安全でないデフォルト設定、公開されたポート、および過剰な権限が含まれます。

リスク: 不必要な権限を持ったコンテナや、無闇にポートを公開しているコンテナの実行。
例1：プリビレッジドコンテナ (Privileged Containers)。 プリビレッジドモード（--privileged）でコンテナを実行すると、ホストマシンのほぼすべてのケーパビリティ（Capabilities）がコンテナに付与されます。これは極めて危険であり、コンテナ内でのいかなる侵害も、即座にホストマシンの侵害へと直結します。脆弱なWebアプリケーションを実行しているプリビレッジドコンテナが侵害されたシナリオを想像してください。攻撃者はその後、コンテナの権限を利用してホストマシンのシステムファイルにアクセスし、改ざんすることが可能になります。
例2：公開されたポート。 適切なファイアウォールルールがない場合、ポートを公開すると、未承認のユーザーがコンテナ内で実行されているサービスにアクセスできる可能性があります。あるデータベースコンテナが、認証メカニズムなしにポート3306をパブリックネットワークに公開していると仮定します。攻撃者は直接データベースに接続し、データを窃取または破壊する可能性があります。
例3：リソースリミットの欠如。 リソース制限（CPU、メモリ）を設定しないと、DoS（Denial of Service）攻撃を引き起こす可能性があります。つまり、1つのコンテナが利用可能なすべてのリソースを消費し、他のコンテナやホストマシンシステムのリソースを枯渇（スターベーション）させてしまいます。コンテナ内で粗悪なコードで書かれたアプリケーションがメモリリークを起こしている状況を想像してください。リソース制限がない場合、このコンテナはホストマシンの全メモリを使い果たし、システム全体をクラッシュさせる可能性があります。
防御策:

絶対に必要でない限り、プリビレッジドモードでのコンテナ実行は避けること。特定の権限が必要な場合は、--cap-add と --cap-drop を使用して、必要なケーパビリティを正確に付与してください。
ポートマッピングを慎重に管理し、ファイアウォール（iptablesやクラウドのセキュリティグループなど）を使用して公開ポートへのアクセスを制限すること。
リソース枯渇を防ぐため、コンテナにリソースリミット（CPU、メモリ）を設定すること。

実際の事例: ある企業がコンテナ化アプリケーションをデプロイした際、推測が容易なデフォルトの root パスワードを使用していました。攻撃者はアクセス権を取得し、それを踏み台としてネットワーク上の他のシステムへラテラルムーブメント（横展開）を行いました。

1.3 イメージ関連のリスク

イメージはコンテナの基盤です。イメージに関連するセキュリティリスクには、信頼できないベースイメージの使用、イメージレイヤーに存在する脆弱性、およびイメージ内にハードコーディングされたシークレット（機密情報）が含まれます。

リスク: 既知の脆弱性が存在する、またはセンシティブな情報が含まれるイメージの使用。
例1：脆弱なベースイメージ。 ベースイメージには多くの場合、既知の脆弱性を持つ時代遅れのソフトウェアパッケージが含まれています。脆弱なベースイメージの上にアプリケーションをビルドすると、アプリケーションもその脆弱性を引き継ぐことになります。例えば、未修正のセキュリティ上の欠陥がある古いUbuntuイメージを使用すると、アプリケーションもその欠陥の危険にさらされます。
例2：イメージ内のシークレット (Secrets)。 DockerfileやアプリケーションコードにAPIキー、パスワード、SSHキーなどのセンシティブな情報を誤って含めたままイメージをビルドすると、そのイメージへのアクセス権を持つすべての人にシークレットが露出してしまいます。開発者がAWS APIキーをコードにハードコーディングしてDockerイメージをビルドしたと仮定します。そのイメージがパブリックなイメージレポジトリにプッシュされた場合、誰でもAPIキーを抽出し、その企業のAWSリソースにアクセスできるようになります。
例3：悪意のあるイメージ。 信頼できないソースからイメージをダウンロードして使用すると、環境にマルウェアやバックドアを導入してしまう可能性があります。開発者が、未知のレポジトリから一見正当に見えるイメージを無意識にプルしたと想像してください。このイメージには、データを盗み出したりホストマシンシステムを破壊したりする悪意のあるコードが含まれている可能性があります。
防御策:

公式で信頼できるベースイメージを使用すること。
Clair、Trivy、Anchoreなどのツールを使用して、イメージの脆弱性を定期的にスキャンすること。
シークレットを決してイメージに埋め込まないこと。代わりに環境変数やDocker Secretsを使用してください。
Docker Content Trust (DCT) を実装して、イメージのインテグリティ（完全性）とオーセンティシティ（真正性）を検証すること。

実際の事例: 2018年に行われたDocker Hubの分析では、多数のイメージにマルウェア、暗号通貨マイナー、その他の悪意のあるソフトウェアが含まれていることが発見されました。

1.4 カーネルレベルのエクスプロイト

コンテナはホストマシンのカーネルを共有しているため、カーネルの脆弱性はそのホストマシン上で実行されているすべてのコンテナに影響を与える可能性があります。

リスク: 複数のコンテナに影響を及ぼすカーネルの脆弱性。
例: Linuxカーネルにゼロデイ脆弱性（Zero-day vulnerability）が発見されたと仮定します。攻撃者はこの脆弱性をエクスプロイトしてホストマシンのOSのコントロールを取得し、その結果、ホスト上で実行されているすべてのコンテナを制御することが可能になります。
防御策:

ホストマシンのOSカーネルを最新のセキュリティパッチでアップデートされた状態に保つこと。
セキュリティのために特別に設計されたコンテナ最適化OS（Flatcar Container LinuxやBottlerocketなど）の使用を検討すること。

実際の事例: Dirty COW（CVE-2016-5195）は、権限昇格を可能にする重大なLinuxカーネルの脆弱性でした。このリスクを軽減するためには、カーネルへの迅速なパッチ適用が不可欠でした。

1.5 ネットワークセキュリティの隠れたリスク

コンテナはネットワークを通じて互いに通信し、また外部の世界とも通信します。不適切なネットワークのコンフィギュレーションは、セキュリティの脆弱性につながる可能性があります。

リスク: コンテナネットワークへの不正アクセス。
例1：ブリッジネットワーク (Bridge Network) の脆弱性。 コンテナがデフォルトのブリッジネットワークに接続されている場合、コンテナ間のトラフィックは通常暗号化されていません。1つのコンテナへのアクセス権を取得した攻撃者は、同一ネットワーク上にある他のコンテナ間のトラフィックを盗聴またはインターセプトする可能性があります。
例2：ホストネットワーク (Host Network) の脆弱性。 host ネットワークモードを使用すると、Dockerのネットワーク分離（アイソレーション）がバイパスされ、コンテナがホストマシンのネットワークインターフェースに直接公開されます。これによりパフォーマンスは向上しますが、コンテナがホストマシンを標的としたネットワークベースの攻撃に対して脆弱になることを意味します。ホストマシンが侵害されれば、コンテナも侵害されます。
例3：ネットワークセグメンテーション (Network Segmentation) の欠如。 適切なネットワーク分離が行われていない場合、すべてのコンテナが同じネットワーク上に存在する可能性があり、アタックサーフェス（攻撃対象領域）が拡大します。1つのコンテナが侵害されると、攻撃者は他のコンテナに容易にアクセスできます。Webアプリケーションとデータベースが同じネットワーク上で実行され、ファイアウォールルールが一切ない状況を想像してください。Webアプリケーションが侵害された場合、攻撃者はデータベースに直接接続できてしまいます。
防御策:

カスタムDockerネットワーク（ユーザー定義のブリッジネットワーク）を使用して、異なるグループのコンテナを分離すること。
絶対に必要でない限り、host ネットワークモードの使用は避けること。
ホストをまたぐセンシティブなトラフィックには、暗号化されたオーバーレイネットワーク（Docker Swarmを使用する際のIPSecなど）を使用すること。

実際の事例: ある企業では、攻撃者がWebアプリケーションコンテナの脆弱性をエクスプロイトし、侵害されたコンテナを利用して同一ネットワーク上のデータベースコンテナにアクセスしたことが原因で、データ侵害が発生しました。

2. リスクの特定と対応のためのベストプラクティスまとめ

Dockerのセキュリティリスクの特定と対応は継続的なプロセスであり、プロアクティブな予防策とリアクティブな対応策を組み合わせる必要があります。

Dockerの定期的なアップデート: Dockerを最新の状態に保ち、最新のセキュリティパッチと機能を利用できるようにします。
最小限のベースイメージの使用: 軽量なイメージを使用することでアタックサーフェスを縮小できます（つまり、含まれる不要なパッケージが少ないほど、潜在的な脆弱性も少なくなります）。Alpine Linuxは、最小限のベースイメージをビルドするための一般的な選択肢です。
イメージの脆弱性スキャン: イメージをデプロイする前に、TrivyやClairなどのツールを使用して、既知の脆弱性がないかスキャンします。
最小権限の原則の実装: コンテナ内でアプリケーションを root ユーザーとして実行することは極力避けてください。Dockerfile内で専用のユーザーとグループを作成し、アプリケーションの実行に必要な最小限の権限のみを付与します。
リソースリミットの使用: CPUとメモリの制限を設定し、リソースの枯渇やDoS攻撃を防ぎます。
安全なネットワークコンフィギュレーション: Dockerネットワークを使用してコンテナを分離し、不必要なポートの公開を制限します。
シークレット管理 (Secrets Management): パスワードやキーをイメージに埋め込むことは避けてください。（極度にセンシティブではないデータには）環境変数を使用するか、HashiCorp Vault、Docker Secrets、またはクラウドプロバイダーのKMSなどの専用のシークレット管理ツールを使用してセンシティブな情報を管理します。
Docker Content Trust (DCT) の有効化: DCTを有効にしてイメージの署名検証を強制し、信頼できるパブリッシャーによって署名されたオリジナルイメージを確実にプルするようにします。
モニタリングとロギング: セキュリティインシデントを検知して対応するために、堅牢なモニタリングとロギング（コンテナログやDockerデーモンログの収集など）を実装します。