暗号理論におけるケルクホフスの原則の間接的な解釈として、「暗号システムは、鍵以外のすべてが攻撃者に知られていても安全でなければならない」とされています。
この原則は、現代のセキュリティにおける重要な真実、すなわち「秘匿性は必ずしも保護ではない」という事実の基盤となっています。同様に、コンテナ化は現代のソフトウェアデプロイメントにおける強力なツールであり、正しく実装されればネットワーク内でのラテラルムーブメントを防ぐことができますが、コンテナ内のアプリケーションが侵害されることを防ぐものではありません。
コンテナは利便性を提供しますが、強固なセキュリティがなければリスクも同時に内包します。驚くべきことではありませんが、本番環境で稼働しているコンテナイメージの60%が既知の脆弱性を抱えており、サイバー脅威への扉を開いています。
では、どのようにしてコンテナを潜在的な侵害から守るのでしょうか？その答えは、あらゆるレイヤーの脆弱性に対応し、隙間を残さない包括的なコンテナセキュリティチェックリストから始まります。
本記事では、コンテナセキュリティチェックリストと、コンテナを堅牢に守るためのベストプラクティスを紹介します。
コンテナセキュリティとは？
コンテナセキュリティとは、コンテナ化されたアプリケーションおよびそれを支えるインフラストラクチャを、ライフサイクル全体を通じて脆弱性や脅威から保護するプロセスです。
これには、コンテナエンジン、ホストOS、オーケストレーションプラットフォーム（Kubernetesなど）、そしてコンテナ自体まで、スタック全体のセキュリティが含まれます。
コンテナセキュリティの重要な要素は、ベースイメージからコンテナ内のアプリケーションコードまで、継続的なスキャンを行うことです。
攻撃を示唆するランタイムリスクを積極的に監視し、使用するコンテナイメージが信頼できるソースから取得され、既知の脆弱性がないことを確認する必要があります。
また、コンテナの分離を確実に実行しなければなりません。権限昇格や誤ったネットワーク設定など、弱点がないか二重に確認してください。
環境から脅威を積極的に排除するために取れる対策は他にも多数あります。幅広いプラクティス、ツール、ポリシーを含む強固なコンテナセキュリティプロトコルやチェックリストを用いることで、開発・デプロイからランタイム、廃棄に至るまで、コンテナのライフサイクル全体を保護できます。
コンテナセキュリティチェックリストの重要性
コンテナ環境は多くの要素が複雑に絡み合っています。そのセキュリティを管理するには、システムが必要です。ガイドラインやチェックリストを手元に置くことで、完全にセキュアなDockerやKubernetesコンテナを迅速にデプロイすることができます。
時間の節約以外にも、セキュリティチェックリストには以下のような利点があります：
- 標準化：コンテナライフサイクルの各ステップを標準化することは、均一性を確保し、重大なミスを防ぐ鍵となります。複数人で作業する場合、ヒューマンエラーのリスクは常に存在します。明確なタスクガイドラインがあれば、全員が同じ認識で作業でき、スムーズに進行します。
- 包括的なカバレッジ：コンテナ化環境には、イメージ、レジストリ、ネットワーク、ランタイムなど複数の構成要素があります。これらの要素をシステムに導入する前にチェックを行うことが必須です。これにはイメージスキャン、アクセス制御、ネットワークセグメンテーション、ランタイム監視などが含まれます。
- 効率性と一貫性：チェックリストは、セキュアなコンテナを保証するための追加ステップであり、運用の効率性と一貫性を高めます。また、チームはセキュリティベストプラクティスの参照ポイントを持つことで、手順の抜け漏れを減らせます。
- コンプライアンス：サイバー脅威やデータ侵害の増加を受け、政府や規制機関は厳格な要件を定めています。明確なコンテナセキュリティチェックリストは、ロールベースアクセス制御（RBAC）、イメージスキャン、DockerやKubernetesのCISベンチマーク準拠などのベストプラクティスを徹底し、監査用のログやモニタリングも確保し、GDPR、HIPAA、PCI-DSSなどのフレームワーク要件を満たします。
- 脅威のプロアクティブな軽減：デプロイ前にコンテナライフサイクル全体を二度確認するのは有効な手段であり、チェックリストがそれを支援します。最初の確認で全てのセキュリティ対策が実装されているかを確認し、二度目の確認で設定漏れや新たな脅威を検出し、重大な問題となる前に対処できます。
10の主要なコンテナセキュリティチェックリスト
コンテナセキュリティチェックリストの重要性を確認したところで、実際に実装すべきセキュリティチェックについて詳しく見ていきましょう。
以下は、DockerおよびKubernetesのセキュリティチェックリストであり、セキュリティプロトコルに必須のステップを簡潔にまとめています：
イメージセキュリティ
- 公式リポジトリから信頼できるベースイメージのみを使用する。
- レジストリへのイメージのプッシュ／プル権限を制限する。
- コンテナイメージを定期的に脆弱性スキャンする。
- 脆弱なイメージのデプロイをブロックする、またはネットワークアクセスを制限する。
- イメージをプッシュする前に、鍵やトークンなどの機密データを検出する。
- イメージは必要な依存関係のみを含む最小構成とする。
- イメージの自動パッチ適用とアップデートを実施する。
アクセスと権限
- コンテナをroot権限で実行しない。
- コンテナが過剰な権限を取得したり、不要なシステムコールを実行したりしないようにする。
- コンテナおよびユーザーに最小権限の原則を適用する。
- 特定のファイルやディレクトリを変更できるコンテナを制御する。
- PodSecurity Admissionを使用して、機密性の高いケイパビリティやリソースへのアクセスを制限する。
- ロールベースアクセス制御（RBAC）を使用し、重要なAPIエンドポイントやコンテナリソース操作（get`, `list、watch、secretsなど）へのアクセスを制限する。
- コンテナ環境へのアクセスには多要素認証（MFA）を利用する。
ネットワークセキュリティ
- ネットワークセグメンテーション（例：Dockerネットワークポリシー）でコンテナを分離する。
- パブリック向けサービスは、各種ポートやプロトコルでトラフィックをフィルタリングして保護する。
- データ転送時は暗号化通信（例：TLS）を使用する。
- サービスメッシュやディープパケットインスペクションによるLayer 7制御でHTTP/HTTPSポリシーを強制する。
- Layer 3および4のトラフィックを制限し、IPベースやポートベースのアクセス制御でアクセスを制限する。
- 選択したContainer Network Interface（CNI）プラグインがKubernetes Network Policiesをサポートしていることを確認する。
- 全ワークロードに対してインバウンド・アウトバウンドのネットワークポリシーを適用し、デフォルトで全トラフィックを拒否するポリシーを設定する。
- 重要なコンポーネント（Kubernetes API、Kubelet APIなど）がパブリックに公開されていないことを確認する。
- トラフィックを暗号化し、クラスター内のワークロード間通信にはMutual TLS（mTLS）で認証する。
ランタイムセキュリティ
- コンテナのランタイム挙動を監視し、不審なアクティビティを検出する。
- Linuxセキュリティモジュールを利用して、コンテナのホストリソースへのアクセスを制限する。
- サービス拒否攻撃を防ぐため、CPUやメモリなどのリソース制限を実装する。
- ランタイムAPIやデーモンへのアクセスを制限し、稼働中のコンテナの改ざんを防ぐ。
- 全てのコンテナアクティビティをリアルタイムでログ・監査する。
脆弱性およびパッチ管理
- コンテナおよびホストシステムを定期的に脆弱性スキャンする。
- 継続的インテグレーションパイプラインで設定ファイルのコンプライアンススキャンを行い、セキュリティ設定ミスの自動チェックを組み込む。
- イメージ署名（Docker Content Trust）を利用し、コンテナイメージの完全性を検証する。
- 静的コード解析を実施し、アプリケーションコードや依存関係の脆弱性を特定する。
シークレット管理
- 機密データ（APIキー、パスワードなど）はシークレット管理ツールに保存する。
- コンテナイメージや環境変数にシークレットをハードコーディングしない。
- 定期的な監査を実施し、Secrets APIへのアクセス権を確認し、暗号鍵をローテーションする。
- Kubernetes APIサーバーでetcd内のシークレットデータを暗号化し、保存データの暗号化を実施することで追加の保護層を設ける。
- トークンの有効期限を短く設定し、トークン漏洩時の影響を最小化する。
オーケストレーションセキュリティ
- コンテナオーケストレーター（例：Docker）を強力なアクセス制御で保護する。
- ロールベースアクセス制御（RBAC）を有効化し、ユーザーやサービスアカウントに最小権限を徹底する。
- オーケストレーターのサービス定義や設定にはバージョン管理（Gitなど）を導入する。
- オーケストレーター制御プレーンへの全APIリクエストのロギングを有効化する（例：Kubernetesの監査ログ）
セキュアな設定
- コンテナ内の不要なサービスやポートを無効化する。
- 書き込み不要なコンテナには読み取り専用ファイルシステムを使用する。
- 可能な限り、コンテナをステートレスかつイミュータブルに保つ。
バックアップと災害復旧
- コンテナ設定やアプリケーションデータを定期的にバックアップする。
- etcdのスナップショット保存コマンドを活用し、時点バックアップでバックアップの一貫性を確保する。
- クラスタコンポーネントの障害を意図的に発生させ、リストアプロセスが期待通りに機能するか災害シミュレーションを実施する。
コンプライアンスと監査
- 業界のセキュリティ標準（例：GDPR、PCI-DSS）への準拠を徹底する。
- コンテナセキュリティポリシー、ログ、アクセス制御設定を定期的に監査する。
- コンテナ環境に対して定期的なセキュリティペネトレーションテストを実施する。
CNAPPマーケットガイドコンテナセキュリティのベストプラクティス
コンテナセキュリティチェックリストを紹介しましたが、さらにコンテナ化環境を強化するためのベストプラクティスをいくつか挙げます：
- 信頼できるベースイメージの使用：コンテナの基盤はイメージです。信頼できるソースから取得し、自動イメージスキャンや定期的なパッチ適用ツールを利用してください。CI/CDパイプラインに直接統合できるツールを使い、各ステージでベースイメージをチェックしましょう。
- 最小権限の原則の実装：コンテナの権限を厳格に管理します。rootでの実行を避け、システムリソースへのアクセスを制限して潜在的な脅威ベクトルを抑制します。CISベンチマークを用いてホストOSをハードニングし、最小限のサービスのみを稼働させ、SentinelOneのようなツールでシステムコールレベルの攻撃面を削減します。コンテナはホストカーネルを共有するため、これは重要です。
- Infrastructure as Code（IaC）のセキュリティ：リスクのある設定が本番環境に到達しないよう、KubernetesマニフェストなどのIaCテンプレートを利用し、デプロイ前にポリシー違反や設定ミス（過度に許可されたIAMロールや公開ポートなど）をスキャンします。
- クラウド設定のハードニング：VPCやプライベートネットワークによるクラウドリソースの分離を徹底し、最小権限アクセス制御でクラウドサービスをハードニングします。オープンなS3バケットや公開管理インターフェースなど、クラウド設定ミスの継続的監視を実施します。
- 外部脆弱性の低減：サードパーティ依存関係の脆弱性（主にビルド時に発見）は、アプリケーションの弱点となります。OSおよびアプリケーション依存関係の既知CVEを自動スキャンし、ライブラリやパッケージを定期的に更新します。
- オーケストレーターおよびランタイムのベンチマーク制御：Kubernetes Admission Controllerなどのオーケストレーターセキュリティ制御を利用し、デプロイ前にセキュリティポリシーを強制します。Kubernetes CISベンチマークなどのランタイムベンチマークチェックを実施し、オーケストレーターと稼働中のコンテナを定期的に監査します。
- ネットワークセグメンテーション：コンテナ間トラフィックを制御するポリシーを作成・適用し、攻撃面を縮小します。コンテナ化ワークロードのマイクロセグメンテーションにより、侵害時の影響を限定し、ネットワークセキュリティを向上させます。
- リソース制限：各コンテナのCPU、メモリ、ストレージにリソース制限を適用することで、単一コンテナによるシステムリソースの枯渇を防ぎます。リソースが枯渇すると、サービス状態や運用上の問題が発生する可能性があります。
- アクティビティの監視とログ記録：セキュリティ脅威にはリアルタイムで対応する必要があります。コンテナの挙動を可視化できるツールを導入し、脅威の迅速な特定と対処を可能にします。
- セキュアなCI/CDパイプライン：コンテナライフサイクルの各段階（コードコミットからデプロイまで）でセキュリティチェックを組み込み、開発プロセス中に脆弱性が持ち込まれるのを防ぎます。
- セキュリティアップデートの自動化：自動化ツールを利用し、ダウンタイムなしでコンテナやオーケストレーターにセキュリティパッチやアップデートを適用します。
- コンプライアンスとポリシーの強制：コンテナを定期的に監査し、組織および規制ポリシーへの準拠を確認します。ポリシー強制ツールを活用し、環境全体で一貫したセキュリティ基準とコンプライアンスを維持します。
避けるべき一般的なコンテナセキュリティのミス
2019年2月、DockerチームはCVE-2019-5736の脆弱性を公表しました。この脆弱性により、攻撃者はホストのバイナリを上書きし、ホストシステムへのアクセスや、コンテナ内でrootとしてコマンドを実行できる可能性がありました。
AWS、RedHat、Microsoft Azureなど複数の組織もこの脆弱性を発見し、自社製品にパッチを適用しました。
2021年には、CVE-2021-3490の脆弱性がLinuxカーネルのextended Berkeley Packet Filter（eBPF）に関連する欠陥を悪用しました。
この脆弱性により、Kubernetesのデフォルトseccompプロファイルを通じてeBPFにアクセスできる侵害されたコンテナ内から、攻撃者がホスト上で任意のコードを実行できました。これらのプロファイルは必要なシステムコールを制限しておらず、一部の構成が露出していました。
これらの事例は、コンテナセキュリティのわずかな見落としがアプリケーションの完全性を損ない、環境をリスクにさらすことを示しています。
他にも注意すべき一般的なコンテナセキュリティのミスは以下の通りです：
- パブリックイメージが安全だと仮定すると、侵害されたデプロイにつながる可能性があります。経験豊富な開発者による徹底的なレビューなしに外部イメージを信用しないでください。
- コンテナを過度に多くのオープンチャネルにさらすと、攻撃面が拡大します。root権限でコンテナを公開状態にしないようにし、ネットワークインタラクションの弱点を見直してください。
- コードライブラリを統合する前に脆弱性の精査やスキャンを怠ること
- 正確なログ記録を維持しないと、セキュリティ問題の早期発見が困難になります。
- CI/CDパイプラインのセキュリティ（ビルドやデプロイ時のセキュリティチェックの省略）を無視すると、開発初期段階で脆弱性が持ち込まれる可能性があります。
SentinelOne Cloud Workload Security for Containers
すべてのコンテナ化環境を効果的に保護するには、全ノードにわたる統一的な戦略が必要です。Q2は、1,200以上の銀行、信用組合、金融機関にサービスを提供する大手金融サービスプロバイダーです。2,200万以上のエンドユーザーと65,000のコンテナをパブリッククラウドで運用しており、Q2は全環境でSentinelOneのCloud Workload Security for Containersを導入しています。Q2と同様に、このソリューションの多くの機能とメリットを活用し、異常を即座に把握し、強固なセキュリティ体制を維持できます。
主な機能とメリット
- AWS、Azure、GCP、オンプレミスデータセンターを含むマルチクラウド環境での包括的なハイブリッドクラウドワークロード保護
- ランサムウェア、ゼロデイエクスプロイト、暗号通貨マイナー、ファイルレス攻撃をブロック
- eBPFベースのエージェントアーキテクチャにより、OSプロセスレベルでリアルタイムの可視性を提供し、カーネルモジュールに依存せずに詳細なテレメトリを取得
- 5億以上のマルウェアシグネチャデータセットを活用したファイルアーキテクチャ解析のための静的AIエンジン
- 時間的分析を用いてパターンを評価し、静的検知を回避する悪意のある挙動を検出する行動AIエンジン
- サーバー、VM、コンテナ、Kubernetes全体でのマシンスピード攻撃のリアルタイム検知
- 自動復旧による最大限のワークロード可用性
- 調査とインシデント対応の迅速化、脅威ハンティングの強化
- Workload Flight Data RecorderTM
- ランタイムセキュリティによるイノベーションの加速（運用を妨げない）
- カーネル依存なし。低CPU・メモリオーバーヘッド。
- 安定性とパフォーマンスのためのeBPFアーキテクチャ
- Docker、コンテナ、cri-oランタイムをサポート
- 自動スケーリング保護
- リアルタイムCWPP
- セルフマネージドおよびマネージドK8sサービスをサポート
- Amazon Linux 2023を含む14の主要Linuxディストリビューションに対応
- Snykとの連携（別途購入）
さらに、SentinelOneのCloud-Native Application Protection Platform（CNAPP）は、Kubernetes Security Posture Management（KSPM）やCloud Security Posture Management（CSPM）などの機能により、クラウドネイティブアプリケーションのコンプライアンスとセキュリティを強化します。
サーバー、VM、コンテナ向けのAI搭載クラウドワークロード保護（CWPP）。実行時の脅威をリアルタイムで検知・阻止します。
よくある質問
コンテナのセキュリティを確保するためには、多層にわたる広範なアプローチが必要です。まずは以下を実施してください。
- 信頼できるベースイメージを使用し、脆弱性について頻繁にスキャンを行い、イメージを最小限に保つことで攻撃対象領域を減らします。
- 最小権限の原則を適用し、コンテナには必要な権限のみを付与し、決してrootとして実行しないようにします。
- コンテナのアクティビティをリアルタイムで継続的に監視し、不審な挙動を検出するとともに、ビルドから実行時まであらゆる段階で脆弱性スキャンを実施します。
- 最後に、ホストおよびオーケストレーターにセキュリティパッチやネットワークポリシーを適用して適切にハードニングし、コンテナ間の通信を制限して潜在的な脅威を低減します。
Container Security Initiative（CSI）は主に7つの要素で構成されています。これには以下が含まれます：
- イメージのスキャン
- ランタイムの保護
- アクセス制御
- ネットワークの保護
- コンプライアンス管理
- 監視
- インシデント対応
SentinelOne Singularity Cloud Workload Security (CWS) プラットフォームは、コンテナセキュリティにおいて重要な役割を果たします。コンテナ化されたアプリケーションのライフサイクル全体を保護します。このプラットフォームはランタイム保護を自動化し、脆弱性管理やコンプライアンスの強制を行います。Kubernetesなどのシステムと連携し、パブリッククラウドおよびプライベートクラウドの両方で、リアルタイムにコンテナを可視化・保護します。
コンテナセキュリティのライフサイクルには、主に5つのステップがあります。
- イメージセキュリティ： 安全性が確認されたイメージを使用し、脆弱性を見つけるために定期的にチェックします。
- ビルドセキュリティ： コンテナのビルドプロセスが安全なルールと手法に従っていることを確認します。
- デプロイメントセキュリティ： コンテナを展開する際に、セキュリティポリシーの適用、最小権限の付与、安全なネットワーク設定を行います。
- ランタイムセキュリティ： コンテナの異常な動作を監視し、ランタイムセキュリティポリシーを適用し、ネットワークの分離を維持します。
- 廃止： コンテナを使用停止にする際、すべての機密データを確実に消去します。
