現代のシステム開発において、DockerやKubernetesなどのコンテナ技術は、開発標準として完全に定着しました。デジタルトランスフォーメーション（DX）の推進とともに、アジャイル開発やDevOpsの実践が進み、その中核にコンテナ技術が位置付けられています。
しかし、利便性の裏側には新たなセキュリティリスクが存在します。従来のオンプレミス環境や仮想マシン（VM）とは異なるコンテナ特有のアーキテクチャは、攻撃者にとって新たな標的となります。「コンテナは隔離されているから安全」という誤解が、重大なセキュリティインシデントを招く原因となっています。
情報処理安全確保支援士試験においても、クラウドセキュリティの一環として、コンテナやオーケストレーションツールのセキュリティ設定に関する出題が増加しています。物理層からアプリケーション層までを一貫して防御する従来の考え方に加えて、コンテナイメージの管理やランタイム保護といった新しい視点が求められます。
本記事では、Docker単体のセキュリティから、Kubernetes（K8s）クラスターのセキュリティまで、試験合格に必要な知識を網羅的かつ実践的に解説します。技術の表面的な暗記ではなく、アーキテクチャからリスクを理解し、適切な対策を導き出せる思考力を養います。
コンテナ技術の基本構造とセキュリティ特性
コンテナセキュリティを理解するには、その構造的特性を深く理解する必要があります。仮想マシンと比較することで、セキュリティ上の境界線がどこにあるかを明確にしましょう。
仮想マシンとコンテナの決定的な違い
従来の仮想マシン（VM）は、ハードウェア上にハイパーバイザーという仮想化ソフトウェアを介して、ゲストOSごと環境を構築します。各VMは完全に独立したカーネル（OSの中核部分）を持って動作するため、高い隔離性が実現されています。
一方、コンテナ（Dockerなど)は、ホストOSのカーネルを複数のコンテナで共有します。コンテナエンジン（Docker Engineなど）が、Linuxの「Namespace（名前空間）」と「Cgroups（コントロールグループ）」を利用して、プロセスやリソースを論理的に隔離しているのです。
この「カーネル共有」という特性が、コンテナセキュリティ最大の要点です。コンテナ内のプロセスがカーネルの脆弱性を悪用した場合、コンテナの壁を突破し、ホストOSそのものや同じホスト上で稼働する他のコンテナを乗っ取ることが可能になります。これを「コンテナブレイクアウト（Container Breakout）」と呼びます。
コンテナの隔離技術：NamespaceとCgroups
コンテナのセキュリティを支える主要なLinuxカーネル機能を理解しましょう。
Namespace（名前空間）
プロセスに対し、システムリソースを独立した空間として見せる技術です。これにより、コンテナAからはコンテナBのプロセスが見えないようになります。
- Pid Namespace: プロセスIDの隔離
- Net Namespace: ネットワークインターフェースの隔離
- Mnt Namespace: ファイルシステムマウントの隔離
- User Namespace: ユーザーIDとグループIDの隔離
Cgroups（Control Groups）
プロセスグループごとの物理リソース（CPU、メモリ、ディスクI/Oなど）の使用量を制限・隔離する技術です。特定のコンテナが暴走してCPUを100%占有し、他のコンテナやホストOSを停止させる「DoS攻撃（Denial of Service）」のような状態を防ぎます。
支援士試験では、これらの技術用語そのものが問われることは少ないものの、「なぜコンテナ間の通信が制限されるのか」「なぜリソース制限が必要なのか」という設問の背景には、必ずこの仕組みが存在しています。
Docker環境における主要な脅威と対策
Docker単体のコンテナ環境において、具体的なリスクと対処方法を見ていきます。攻撃者の視点では、狙い所は「イメージ」「設定」「ランタイム」の3点に集約されます。
1. 信頼できないコンテナイメージのリスク（サプライチェーン攻撃）
コンテナの利点は、Docker Hubなどのレジストリから既存のイメージをダウンロードして即座に環境構築できる点です。しかし、公開イメージが安全である保証はありません。
主なリスク
- マルウェアの混入: 攻撃者が意図的にバックドアやクリプトマイナー（仮想通貨採掘ツール）を仕込んだイメージを公開しているケースがあります
- 脆弱なライブラリの放置: 公式イメージであっても、ベースとなっているOSやライブラリ（OpenSSLなど）に既知の脆弱性（CVE）が含まれたまま放置されていることがあります
対策：イメージスキャンと信頼済みレジストリの利用
イメージスキャンの実施
TrivyやClair、Docker Scanなどのツールを使用し、イメージ内のパッケージ情報を脆弱性データベースと照合します。これをCI/CDパイプライン（開発からデプロイまでの自動化フロー）に組み込み、脆弱性が発見されたイメージはデプロイをブロックする運用が理想的です。
最小構成のイメージ利用
「Distroless」や「Alpine Linux」など、必要最小限のコンポーネントしか含まない軽量イメージを利用します。攻撃に利用できるシェルやツール（curlやwgetなど）が含まれていなければ、侵入後の拡大を防ぐことができます。これは「攻撃対象領域（Attack Surface）の縮小」というセキュリティの基本原則に合致します。
2. 特権モードと不適切な権限管理
Dockerには --privileged というフラグがあります。これを付与してコンテナを起動すると、コンテナ内のプロセスはホストOS上のほぼすべてのデバイスへのアクセス権限を持ちます。これは実質的に、コンテナによる隔離を無効化する危険な設定です。
また、多くのコンテナはデフォルトで root ユーザーとして実行されます。コンテナ内のrootは、対策を講じない限りホストOS上でもroot権限を持つことになります。
対策：Least Privilege（最小権限の原則）の徹底
非特権ユーザーでの実行
Dockerfile内で USER 命令を使用し、root以外の一般ユーザーでアプリケーションを実行するように指定します。
Capabilities（ケーパビリティ）の制限
Linuxのroot権限を細分化した「Capabilities」機能を活用し、Docker実行時に --cap-drop=ALL で全ての権限を剥奪した後、必要な権限（例: --cap-add=NET_BIND_SERVICE）だけを付与します。
ファイルシステムの読み取り専用化
アプリケーションが書き込みを必要としないディレクトリは、--read-only フラグやボリューム設定で読み取り専用としてマウントします。これにより、攻撃者が不正なファイルを設置したり、設定ファイルを改ざんしたりすることを防げます。
3. 機密情報の不適切な管理
開発中、APIキーやデータベースのパスワードをDockerfile内の環境変数（ENV）に直接記述してしまうケースが散見されます。docker inspect コマンドを使えば、誰でもこれらの環境変数を閲覧できてしまいます。
対策：シークレット管理機能の利用
機密情報はコードやイメージに埋め込まず、実行時に外部から注入する仕組みを利用します。Docker SwarmやKubernetesの「Secrets」機能、あるいはHashiCorp Vaultなどの専用ツールを使用し、メモリ上にのみ展開されるように設計します。これにより、機密情報の漏洩リスクを大幅に低減できます。
Kubernetes（K8s）におけるセキュリティ要塞化
Docker単体ではなく、多数のコンテナを束ねて管理するKubernetes環境では、管理対象が広がるため、攻撃ベクトルも多岐にわたります。クラスター全体の要塞化が求められます。
1. Pod間通信の制御（Network Policies）
Kubernetesのデフォルト設定では、クラスター内のすべてのPod（コンテナの集合体）は、他のすべてのPodと通信可能です（フラットなネットワーク）。これは、WebサーバーのPodが侵害された場合、本来通信する必要のない内部のデータベースや管理用Podにまで攻撃が及ぶ（ラテラルムーブメント：横展開）リスクを意味します。
対策：Network Policyによるマイクロセグメンテーション
Kubernetesの NetworkPolicy リソースを使用し、Pod間の通信をホワイトリスト形式で制御します。「Frontend PodからBackend PodへのTCP 8080番ポートのみ許可し、それ以外はすべて遮断」といった詳細なルールを定義します。これは従来のファイアウォール設定を、アプリケーションの構成定義としてコード化するものです。
2. Pod Security Standards (PSS) / Admission Controller
開発者がセキュリティ設定の甘いPod（特権モードなど）を勝手にデプロイしてしまうのを防ぐ仕組みが必要です。
対策：Admission Controllerによるゲートキーパー機能
APIサーバーへのリクエストを検証する Admission Controller を有効化します。特に、Pod Security Admission (PSA) や、より高度なポリシー管理が可能な OPA (Open Policy Agent) Gatekeeper、Kyverno などを導入します。これにより、「rootユーザーでの実行禁止」「ホストパスのマウント禁止」といったポリシーに違反するPodの作成リクエストを、デプロイ前に自動的に拒否することができます。
この仕組みは、開発者の自由度を損なうことなく、組織のセキュリティポリシーを強制的に適用する効果的な手段となります。
3. RBAC（Role-Based Access Control）の厳格化
Kubernetes APIへのアクセス権限管理は、クラスターセキュリティの根幹です。「誰が」「どのリソースに対して」「何ができるか」を厳密に定義する必要があります。
対策：最小権限のロール設計
ServiceAccountの管理
PodがAPIサーバーと通信するために使用するServiceAccountには、デフォルトで権限を与えすぎないようにします。不要であれば automountServiceAccountToken: false を設定し、トークンのマウント自体を無効化します。
RoleとClusterRole
開発者には特定のNamespace内での操作のみを許可する Role を割り当て、クラスター全体に影響を及ぼす ClusterRole（特に cluster-admin）の付与は厳重に制限します。過剰な権限付与は、内部脅威や認証情報の漏洩時に深刻な被害をもたらします。
4. イメージポリシーの強制
Kubernetesクラスターにデプロイ可能なイメージを制限することも重要です。信頼されたレジストリからのみイメージをプルするようにポリシーを設定し、未検証のイメージが本番環境にデプロイされることを防ぎます。
コンテナ環境におけるログ監視とインシデント対応
防御を固めても、侵入される可能性はゼロではありません。コンテナは「短命（Ephemeral）」であるため、インシデント発生時にコンテナが破棄されていると、ログも消滅してしまい、フォレンジック（原因究明）が不可能になります。
ログの永続化と集約
コンテナの標準出力（stdout/stderr）に出力されたログは、ホスト上のファイルとして一時的に保存されるだけです。FluentdやPromtailなどのログ収集エージェントを、各ノードにDaemonSetとして配置し、ElasticsearchやSplunk、クラウドのログ基盤（CloudWatch Logsなど）へリアルタイムに転送・集約する必要があります。
ログの集約により、以下のメリットが得られます：
- コンテナ破棄後もログが保持される
- クラスター全体のログを横断的に検索・分析できる
- 異常パターンの検知やアラート設定が可能になる
- コンプライアンス要件（監査ログの保存期間など）を満たせる
ランタイムセキュリティ監視
従来のアンチウイルスソフトは、コンテナ内部の挙動まで詳細に監視できない場合があります。
Falco
システムコールを監視し、「シェルが起動された」「機密ファイルへのアクセスがあった」「外部への不正な通信が発生した」といった異常検知を行うオープンソースツールです。Kubernetes環境に特化したIDS（侵入検知システム）として機能します。
Falcoは、事前に定義されたルールに基づいて、コンテナ内で発生する異常な動作をリアルタイムで検出します。例えば、Webサーバーコンテナ内で突然シェルが実行された場合、これは攻撃者がコマンド実行権限を奪取した可能性を示すため、即座にアラートを発生させます。
午後試験に向けた記述対策のポイント
情報処理安全確保支援士試験の午後問題で、コンテナセキュリティがテーマになった場合、以下のような観点で記述を求められる可能性が高いです。
1. 対策の必要性を理由付けする
設問例: なぜコンテナをrootユーザーで実行すべきではないのか？
解答例: コンテナブレイクアウトが発生した場合、攻撃者がホストOSの管理者権限を奪取し、システム全体を掌握されるリスクがあるため。
2. サプライチェーンリスクへの言及
設問例: 外部リポジトリのイメージを利用する際のリスクと対策は？
解答例: マルウェア混入や既知の脆弱性が含まれるリスクがあるため、利用前に脆弱性スキャンを実施し、組織内の信頼されたプライベートレジストリ経由でデプロイする。
3. 不変（Immutable）インフラストラクチャの理解
設問例: 稼働中のコンテナにパッチを適用せず、新しいイメージと入れ替える理由は？
解答例: 稼働中の変更は構成管理との乖離（ドリフト）を生み、再現性を損なうため。また、侵害されたコンテナを破棄することで、マルウェアの永続化を防ぐ効果もあるため。
4. 多層防御の観点
設問例: コンテナ環境におけるセキュリティ対策を複数層で説明せよ。
解答例: イメージレベルでの脆弱性スキャン、ランタイムレベルでの権限制限とリソース制限、ネットワークレベルでのマイクロセグメンテーション、運用レベルでのログ監視とインシデント対応という多層防御を実施する。
コンテナセキュリティのベストプラクティス
実務と試験対策の両面から、押さえておくべきベストプラクティスをまとめます。
イメージ管理
- 公式イメージや信頼できるソースからのみイメージを取得する
- 定期的にイメージをスキャンし、脆弱性を検出する
- 最小構成のベースイメージ（Alpine、Distrolessなど）を使用する
- イメージのタグには具体的なバージョンを指定し、
latestタグは避ける - 不要なパッケージやツールを含まない専用イメージを作成する
ランタイムセキュリティ
- コンテナを非rootユーザーで実行する
- 特権モード（
--privileged）の使用を避ける - 必要最小限のCapabilitiesのみを付与する
- ファイルシステムを可能な限り読み取り専用にする
- リソース制限（CPU、メモリ）を適切に設定する
Kubernetesセキュリティ
- Network Policyを使用してPod間通信を制限する
- Pod Security Standardsを適用し、危険な設定を防ぐ
- RBACで最小権限の原則を徹底する
- ServiceAccountトークンの自動マウントを必要最小限に制限する
- Secretsを使用して機密情報を管理する
- Admission Controllerでポリシーを強制する
監視と運用
- すべてのコンテナログを集約して永続化する
- ランタイムセキュリティツール（Falcoなど）で異常を検知する
- 定期的なセキュリティ監査を実施する
- インシデント対応手順を明確化し、訓練を行う
- CI/CDパイプラインにセキュリティチェックを組み込む
【実践】Docker・Kubernetesセキュリティ 理解度チェック
「読んだつもり」で終わらせないために、本記事の要点を網羅した練習問題を用意しました。 仮想マシンとの違い、サプライチェーン攻撃への対策、そしてKubernetesの多層防御など、実務でも即戦力となる知識を問います。
正解・不正解にかかわらず、解説を読むことでさらに理解が深まる構成になっています。ぜひ全問正解を目指して挑戦してください。
まとめ：コンテナセキュリティは多層防御の集大成
コンテナとKubernetesのセキュリティは、決して新しい概念だけで成り立っているわけではありません。
- OSレベル: カーネル機能（Namespace/Cgroups）と権限管理
- ネットワークレベル: マイクロセグメンテーションと通信制御
- アプリケーションレベル: 脆弱性管理とセキュアコーディング
- 運用レベル: ログ監視とCI/CDパイプラインでの自動化
これら、これまでに学んできたセキュリティの基本要素を、コンテナという新しいアーキテクチャに合わせて再構成し、隙間なく積み重ねていく「多層防御」のアプローチこそが正解です。
DockerやKubernetesは、開発スピードを飛躍的に向上させる強力な武器ですが、セキュリティ設定を誤れば、システム全体を危険にさらす可能性があります。本記事で解説した「イメージ」「ランタイム」「オーケストレーション」の3つの視点を持ち、試験対策はもちろん、実務でも安全なコンテナ環境を設計できるエンジニアを目指してください。
コンテナセキュリティの本質は、新しい技術への対応力だけでなく、セキュリティの基本原則を様々な環境に適用できる柔軟な思考力です。Namespace、Cgroups、Capabilitiesといった低レイヤーの仕組みから、Network Policy、RBAC、Admission Controllerといった高レイヤーの制御まで、各層での防御策を理解し、組み合わせることで、真に堅牢なコンテナ環境を実現できます。
情報処理安全確保支援士試験では、こうした多層防御の考え方と、各層での具体的な対策を適切に説明できる能力が評価されます。本記事の内容を基に、コンテナ特有のリスクと対策を自分の言葉で説明できるよう、理解を深めてください。
次回の記事では、この知識を前提として、より広範な「クラウド環境（AWS/Azure）における責任共有モデルと設定ミス対策」について深掘りしていきます。コンテナが動くその基盤となるクラウド自体のセキュリティも、避けては通れない重要なテーマです。引き続き、合格に向けて知識の層を厚くしていきましょう。