システムアーキテクチャ セキュリティ DevOps

Dockerセキュリティ:本番環境でコンテナを守る8つの黄金律

2026年08月31日 1 分で読めます 16 ビュー

Dockerセキュリティ:本番環境でコンテナを守る8つの黄金律

アプリケーション開発において、Dockerはパッケージ化とデプロイを簡素化します。しかし、セキュリティ設定を行わずにDockerコンテナを本番環境(Production)にデプロイすると、システムが攻撃者の容易な標的になってしまう可能性があります。

この記事では、Dockerコンテナのセキュリティを強化し、本番環境のデータを保護するための重要な8つのルールを解説します。

1. ルート権限でコンテナを実行しない

デフォルトでは、特定のユーザーを指定しない限り、Dockerはroot権限でコンテナを実行します。攻撃者がコンテナ内のアプリケーションを制御した場合、脆弱性を悪用してホストマシンのroot権限を取得する可能性があります。

Dockerfileでの対処法:

FROM node:24-alpine WORKDIR /app COPY . . RUN addgroup -S appgroup && adduser -S appuser -G appgroup USER appuser CMD ["node", "server.js"]

権限を制限することで、コンテナが侵害された場合のリスクを軽減できます。

2. イメージのセキュリティ脆弱性をスキャンする

Docker Hubのベースイメージには、公知のセキュリティ脆弱性(CVE)を含む古いパッケージが含まれている場合があります。

これに対処するため、レジストリにプッシュする前にイメージをスキャンします:

trivy image my-app:latest

Trivyのほか、GrypeやDocker Scoutなどのツールを使用して、脆弱性を事前に対策できます。

3. 信頼できるベースイメージのみを使用する

Docker Hubから出所不明のベースイメージをダウンロードして使用すると、マルウェアが含まれていたりバックドアが仕込まれていたりする危険性があります。

解決策:

  • 公式イメージ(Official Image)または検証済みパブリッシャー(Verified Publisher)のみを選択する。
  • 攻撃対象領域(Attack Surface)を減らすため、alpine、distroless、slimバージョンなどの最小限のイメージを優先する。

4. シークレット情報を安全に管理する

データベースのパスワードやAPIキーなどの機密情報をDockerfileや.envファイルにハードコードし、Gitリポジトリにプッシュすることは絶対に避けてください。

ENV命令を使用して機密情報をイメージ内に保存する代わりに、専用のシークレット管理ソリューションを導入します:

  • Docker Secrets または Kubernetes Secrets を使用する。
  • HashiCorp Vault や AWS Secrets Manager などの集中管理ツールを使用する。

5. システムリソースの制限(Resource Limits)

無限ループのバグやDDoS攻撃を受けたコンテナは、ホストサーバーのCPUとRAMをすべて消費し、周囲の他のサービスをクラッシュさせる可能性があります。

docker runコマンドでリソース制限を設定できます:

docker run -d --memory="512m" --cpus="1.5" my-app:latest

または docker-compose.yml 内で直接設定します:

services: web: image: my-app:latest deploy: resources: limits: cpus: '1.5' memory: 512M

6. ファイルシステムを読み取り専用(Read-Only)に設定する

一時ファイルやログを保存するディレクトリを除き、ほとんどのアプリケーションコンテナは内部ファイルシステムに直接データを書き込む必要がありません。

コンテナを読み取り専用モードで実行することで、攻撃者がファイルシステムに悪意のあるコードを書き込むのを防ぎます:

docker run -d --read-only --tmpfs /tmp my-app:latest

上記コマンドにより、コンテナをRead-Onlyモードで実行しながら、RAM上の/tmpディレクトリへの一時データの書き込みを許可できます。

7. Docker Daemonを安全に設定する

Docker DaemonはUnixソケット /var/run/docker.sock を介して通信します。このソケットが信頼できないコンテナにマウントされると、攻撃者がホストマシン全体を乗っ取る可能性があります。

重要な注意点:

  • 本当に必要な場合を除き、/var/run/docker.sock をコンテナ内にマウントしないでください。
  • ネットワーク経由でDockerをリモート管理する場合は、必ずTLS証明書認証(Docker HTTPS socket)を有効にしてください。

8. Dockerとベースイメージを定期的に更新する

新しい脆弱性は毎日発見されています。Docker Engineとベースイメージを常に最新の状態に保つことが、最も効果的な防御策です。

CI/CDパイプラインを構築し、定期的にイメージを自動再構築(Rebuild)して、最新のセキュリティパッチを取り込むようにします。

9. Dockerコンテナセキュリティチェックリスト

  • 一般ユーザー(USER appuser)に変更したか。
  • Trivy や Docker Scout で脆弱性をスキャンしたか。
  • Dockerfile からシークレットや API キーを完全に排除したか。
  • CPU および メモリの制限を設定したか。
  • 可能な限り Read-Only File System を有効にしたか。
  • Docker Socket (/var/run/docker.sock) を共有していないか。
  • 定期的にベースイメージを更新しているか。

まとめ

Dockerのセキュリティ対策は、Dockerfileの記述から本番環境での運用に至るまで、継続的な注意を払うべきプロセスです。

一般ユーザーでの実行、リソース制限、安全なシークレット管理、定期的な脆弱性スキャンなどのベストプラクティスを適用することで、システムの安定性と安全性を高め、情報漏洩のリスクを最小限に抑えることができます。

ビジネス変革の準備はできていますか?

AIとデジタル変革の活用について、ぜひご相談ください。

よくある質問

Dockerイメージスキャンとコンテナランタイムセキュリティの違いは何ですか?
Dockerイメージスキャン(Trivyなど)は、デプロイ前にパッケージ内のセキュリティ脆弱性を検出します。一方、コンテナランタイムセキュリティ(Falcoなど)は、サーバー上でコンテナが実行中の異常な動作をリアルタイムで監視・アラート通知します。両方を組み合わせることで、構築から運用まで包括的な保護を実現できます。
実行中のコンテナがルート権限で動作しているか確認するにはどうすればよいですか?
コマンド docker exec -it <container_name> whoami を実行して確認します。出力結果が root の場合、コンテナは安全な一般ユーザーで保護されていません。これを解決するには、Dockerfile内に非ルートユーザーを作成し、 USER 命令を追加してイメージを再構築してください。

執筆者

VAONチーム

VAONは、実際のビジネス成長を促進する、スケーラブルなウェブ、クラウド、および専任のエンジニアリングソリューションを提供する信頼できるテクノロジーパートナーです。

記事をシェア