暗号学におけるケルクホフの原則を間接的に解釈すると、– 暗号システムは、鍵以外のシステムに関する全てが攻撃者に知られていても安全性を保つべきである。
この原則は、現代のセキュリティに関する重要な真実の基盤です。すなわち、隠蔽性は必ずしも保護ではない。同様に、現代のソフトウェア展開における強力なツールであるコンテナ化は、正しく実装されればネットワーク内での横方向の移動を防ぐかもしれませんが、コンテナ内のアプリケーションが侵害されるのを防ぐことはできません。
コンテナは利便性を提供する一方で、強固なセキュリティがなければリスクも内包します。驚くべきことではありませんが、本番環境で稼働するコンテナイメージの60%は既知の脆弱性に満ちており、サイバー脅威への扉を開いたままにしているのです。
では、コンテナを潜在的な侵害から守るにはどうすればよいのでしょうか？その答えは、あらゆるレイヤーの脆弱性に対処し、隙間を一切残さない包括的なコンテナセキュリティチェックリストから始まります。
本記事では、コンテナを堅牢な要塞のように守るためのセキュリティチェックリストとベストプラクティスをご紹介します。
コンテナセキュリティとは？
コンテナセキュリティとは、コンテナ化されたアプリケーションとそれを支えるインフラストラクチャを、ライフサイクル全体を通じて脆弱性や脅威から保護するプロセスです。
これには、コンテナエンジン、ホストオペレーティングシステム、オーケストレーションプラットフォーム（Kubernetesなど）、そしてコンテナ自体に至るまでのスタック全体のセキュリティ確保が含まれます。
コンテナセキュリティの重要な要素は、ベースイメージからコンテナ内のアプリケーションコードに至るまでの継続的なスキャンです。
攻撃を示唆する可能性のある実行時リスクを積極的に監視すると同時に、使用するコンテナイメージが信頼できるソースから取得され、既知の脆弱性を含まないことを保証する必要があります。
コンテナの分離を完璧に実行することも必須です。特権昇格やネットワーク設定ミスなど、あらゆる脆弱性を再確認してください。
脅威を環境から積極的に排除するその他の対策も複数存在します。多様な手法・ツール・ポリシーを網羅した堅牢なコンテナセキュリティプロトコルやチェックリストにより、ポリシーを網羅した堅牢なコンテナセキュリティプロトコルやチェックリストを用意すれば、開発・デプロイから実行時、廃止に至るコンテナライフサイクル全体を保護できます。
コンテナセキュリティチェックリストの重要性
コンテナ環境は複雑に絡み合った要素の迷宮です。そのセキュリティを管理するには体系的な手法が必要です。ガイドラインやチェックリストを手元に用意することで、完全に保護されたDockerやKubernetesコンテナのデプロイ成功までの時間を短縮できます。
時間節約以外にも、セキュリティチェックリストには以下の利点があります：
- 標準化: コンテナライフサイクルの各ステップを標準化することは、一貫性を確保し重大なミスを防ぐ鍵です。共同作業では常に人的ミスが発生する可能性があります。タスクに関する明確なガイドラインを設けることで、全員が同じ認識を持ち、円滑な運用を実現できます。
- 包括的なカバー範囲: コンテナ化された環境には、イメージ、レジストリ、ネットワーク、ランタイムなど複数の構成要素が存在します。これらの要素をシステムに導入する前にチェックを実行することは必須です。これにはイメージスキャン、アクセス制御、ネットワークセグメンテーション、ランタイム監視などが含まれます。
- 効率性と一貫性: チェックリストはセキュアなコンテナを保証する追加の手順であり、運用に効率性と一貫性をもたらします。さらに、チームはセキュリティベストプラクティスの基準点を持ち、手順の漏れを防ぐことができます。
- コンプライアンス:サイバー脅威やデータ侵害の増加を受け、政府や規制機関は厳格な規制要件を定めています。明確に定義されたコンテナセキュリティチェックリストは、ロールベースアクセス制御（RBAC）、イメージスキャン、DockerおよびKubernetes向けCISベンチマークの順守といったベストプラクティスを適用することでコンプライアンスを確保します。また、監査のためのログ記録と監視を保証し、GDPR、HIPAA、PCI-DSSなどのフレームワーク要件を満たします。
- 脅威の事前軽減:コンテナをデプロイする前に、そのライフサイクル全体を2回確認することは常に有効な手法です。チェックリストはこの実現を支援します。初回確認では全てのセキュリティ対策が実装されていることを保証し、2回目の確認では検証ステップとして、重大な問題となる前に設定漏れや新たな脅威を捕捉します。
コンテナセキュリティチェックリスト10の重要項目
コンテナセキュリティチェックリストの重要性を確認したところで、次にどのセキュリティチェックを実施すべきかを深く掘り下げて理解しましょう。
以下に、セキュリティプロトコルに必須の全手順を簡潔にまとめたDockerとKubernetesのセキュリティチェックリストを示します：
-
イメージセキュリティ
- 公式リポジトリから信頼性と検証済みのベースイメージを使用する。
- レジストリへのイメージのプッシュ/プルを実行できるユーザーを制限する
- コンテナイメージの脆弱性を定期的にスキャンする
- 脆弱なイメージのデプロイをブロックするか、それらのネットワークアクセスを制限する
- イメージをプッシュする前に、キーやトークンなどの機密データを検出する
- イメージを最小限に保ち、必要な依存関係のみを含めることを確認する。
- イメージの自動パッチ適用と更新を実装する。
-
アクセスと権限
- コンテナをroot権限で実行しない。&
- コンテナが過剰な権限を取得したり、不要なシステムコールを行ったりするのを防止する。
- コンテナとユーザーに対して最小権限の原則を実装する。
- 特定のファイルやディレクトリを変更できるコンテナを制御する。
- PodSecurity Admissionを使用して、機密性の高い機能やリソースへのアクセスを制限する。
- ロールベースのアクセス制御（RBAC）を使用して、重要なAPIエンドポイントや、
`get`、`list`、`watch`、、`secrets`などのコンテナリソース操作へのアクセスを制限します。` - 多要素認証（MFA） を使用してコンテナ環境にアクセスします。
ネットワークセキュリティ
- ネットワークセグメンテーション（例：Dockerネットワークポリシー）を使用してコンテナを分離する。
- 各種ポートやプロトコルでのトラフィックフィルタリングにより、公開サービスを保護する。
- 転送中のデータには暗号化通信（例：TLS）を使用する。
- サービスメッシュとディープパケットインスペクションを用いたレイヤ7制御でHTTP/HTTPSポリシーを適用する。&
- IPベースおよびポートベースのアクセス制御を使用してレイヤ3および4のトラフィックを制限し、アクセスを制限する。&
- 選択したコンテナネットワークインターフェース（CNI）プラグインがKubernetesネットワークポリシーをサポートしていることを確認する。
- すべてのワークロードに流入・流出ネットワークポリシーを適用し、デフォルトポリシーとして全トラフィックを拒否する設定を実施する。
- 重要なコンポーネント（Kubernetes API、Kubelet APIなど）が公に公開されていないことを確認してください。
- トラフィックを暗号化し、クラスタ内のワークロード通信認証に相互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 などのツールを用いてシステムコールレベルでの攻撃対象領域を削減することを検討してください。コンテナはホストカーネルを共有するため、これは重要です。
- インフラストラクチャ・アズ・コード（IaC）のセキュリティ確保： リスクの高い設定が本番環境に到達するのを防ぐため、KubernetesマニフェストなどのIaCテンプレートを活用し、デプロイ前にポリシー違反や設定ミス（過度に許可されたIAMロールや公開ポートなど）をスキャンできます。
- クラウド構成の強化: VPCやプライベートネットワークによるクラウドリソースの分離を確保し、最小権限アクセス制御でクラウドサービスを強化します。クラウドの誤設定（公開されたS3バケットや露出された管理インターフェースなど）に対する継続的監視を実施します。
- 外部脆弱性の低減: サードパーティ依存関係（主にビルド時に検出）の脆弱性はアプリケーションの弱点となる可能性があります。OSおよびアプリケーション依存関係における既知のCVEに対する依存関係スキャンを自動化できます。ライブラリとパッケージを定期的に更新してください。
- オーケストレーターとランタイムのベンチマーク制御: Kubernetesアドミッションコントローラーなどのオーケストレーターセキュリティ制御を活用し、デプロイ前にセキュリティポリシーを適用します。オーケストレーターと稼働中のコンテナを定期的に監査するため、ランタイムベンチマークチェック（例：Kubernetes CISベンチマーク）を実施します。
- ネットワークセグメンテーション：コンテナトラフィックを制御し攻撃対象領域を縮小するポリシーを作成・適用します。コンテナ化されたワークロードのマイクロセグメンテーションにより、侵害の影響を制限し、ネットワークセキュリティを向上させます。
- リソース制限： 各コンテナの CPU、メモリ、ストレージにリソース制限を適用することで、コンテナがシステムリソースを枯渇させるのを防ぐことができます。システムリソースが枯渇すると、サービス状態やその他の運用上の問題が発生する可能性があります。
- アクティビティの監視とログ記録：セキュリティ脅威にはリアルタイムで対応する必要があります。コンテナの動作を可視化するツールを導入し、脅威を迅速に特定・軽減できるようにします。
- CI/CDパイプラインのセキュリティ確保: コードコミットからデプロイまでのコンテナライフサイクル全段階でセキュリティチェックを組み込み、CI/CDパイプラインの安全性を確保します。これにより開発プロセス中に脆弱性が導入されるのを防ぎます。
- セキュリティ更新の自動化: 自動化ツールを活用し、ダウンタイムを発生させることなくコンテナやオーケストレーターにセキュリティパッチや更新を適用します。
- コンプライアンスとポリシー適用:組織および規制ポリシーに準拠するため、コンテナを定期的に監査します。ポリシー適用ツールを使用して環境全体にセキュリティポリシーを適用し、一貫したセキュリティ基準とコンプライアンスを維持します。
避けるべき一般的なコンテナセキュリティの過ち
2019年2月、DockerチームはCVE-2019-5736 vulnerability.この脆弱性により、攻撃者はホストのバイナリを上書きし、ホストシステムへのアクセス権を取得し、コンテナ内でroot権限でコマンドを実行することが可能でした。
AWS、RedHat、Microsoft Azureを含む複数の組織もこの脆弱性を発見し、自社製品にパッチを適用しました。
2021年には、CVE-2021-3490 脆弱性がLinuxカーネルの欠陥を悪用しました。この欠陥は拡張バークレーパケットフィルタ（eBPF）に関連するLinuxカーネルの欠陥を悪用しました。&
この脆弱性により、攻撃者はKubernetesのデフォルトのseccompプロファイルを通じてeBPFにアクセス可能な侵害されたコンテナ内から、ホスト上で任意のコードを実行することが可能でした。これらのプロファイルは必要なシステムコールを制限しておらず、特定の環境設定を危険に晒していました。
これらの事例は、コンテナセキュリティにおける小さな見落としがアプリケーションの完全性を損ない、環境にリスクをもたらすことを示しています。注意すべきその他の一般的なコンテナセキュリティ上の過ちには以下があります：
- 公開イメージの安全性を前提とすると、デプロイメントが侵害される可能性があります。経験豊富な開発者による徹底的なレビューなしに外部イメージを信頼してはいけません。
- コンテナを過剰なオープンチャネルに晒すと攻撃対象領域が増大します。ルート権限でコンテナを公開状態に放置せず、ネットワーク通信の潜在的な脆弱性を検証してください。
- コードライブラリをコンテナに統合する前に脆弱性検証とスキャンを実施しないこと
- 正確なログ記録を維持しないことは、セキュリティ問題を迅速に発見することを困難にします。
- ビルドやデプロイ時のセキュリティチェックを省略するなど、CI/CDパイプラインのセキュリティを無視することは、開発の初期段階で脆弱性を導入する可能性があります。
SentinelOne Cloud Workload Security for Containers
すべてのコンテナ環境を効果的に保護するには、全ノードにわたる統一された戦略が必要です。Q2は1200以上の銀行、組合、金融機関にサービスを提供する主要な金融サービスプロバイダーです。2,200万人以上のエンドユーザーと65,000個のパブリッククラウドコンテナを擁するQ2は、全環境にSentinelOneのCloud Workload Security for Containersを導入しています。Q2と同様に、貴社も本ソリューションの数々の機能とメリットを活用し、あらゆる異常を即座に把握し、強固なセキュリティ体制を維持できます。
主な機能とメリット
- AWS、Azure、GCP、オンプレミスデータセンターを含むマルチクラウド環境全体での包括的なハイブリッドクラウドワークロード保護
- ランサムウェア、ゼロデイ攻撃、暗号通貨マイナー、ファイルレス攻撃をブロック
- eBPFベースのエージェントアーキテクチャにより、OSのプロセスレベルでリアルタイム可視化を実現。カーネルモジュールに依存せず深いテレメトリを提供
- 5億件以上のマルウェアシグネチャデータセットを活用したファイル構造解析を行う静的AIエンジン
- 時間軸分析を用い、経時的なパターン評価により静的検知を回避する悪意ある行動を検出する行動AIエンジン
- サーバーVMS、コンテナ、Kubernetes全体でのマシン速度攻撃をリアルタイム検知
- ワークロードの可用性を最大限に高める自動リカバリ
- 調査と IR を加速し、脅威の追跡を強化
- ワークロードのフライトデータレコーダーTM。
- イノベーションを加速する、邪魔にならないランタイムセキュリティ。
- カーネル依存なし。低CPU・メモリオーバーヘッド。
- 安定性とパフォーマンスを実現するeBPFアーキテクチャ
- Docker、コンテナ、cri-oランタイムをサポート
- オートスケーリング保護
- リアルタイム CWPP
- セルフマネージドおよびマネージド K8s サービスのサポート
- Amazon Linux 2023 を含む 14 の主要な Linux ディストリビューションのサポート&
- Snykとの連携（別途購入）
さらに、SentinelOne の クラウドネイティブアプリケーション保護プラットフォーム (CNAPP) は、次のような機能によりコンテナセキュリティの強化を支援します。Kubernetesセキュリティポスチャ管理（KSPM）やクラウドセキュリティポスチャ管理（CSPM）により、クラウドネイティブアプリケーションのコンプライアンスとセキュリティを確保します。
FAQs
コンテナのセキュリティを確保するには、多くの層をカバーする包括的なアプローチが必要です。まず以下のことを行います：
- 信頼できるベースイメージを使用し、頻繁に脆弱性スキャンを実施。攻撃対象領域を最小化するため、イメージを最小限に抑える。
- 最小権限の原則を適用し、コンテナに必要な権限のみを制限し、rootとして実行しないこと。
- コンテナの活動をリアルタイムで継続的に監視し、不審な動作を検知するとともに、ビルドから実行時までの全段階で脆弱性スキャンを実施すること。
- 最後に、ホストとオーケストレーターをセキュリティパッチとネットワークポリシーで適切に強化し、コンテナ間の通信を制限して潜在的な脅威を低減してください。
コンテナセキュリティイニシアチブ（CSI）には7つの主要な構成要素があります。これらは以下の通りです：
- イメージのスキャン
- ランタイムの保護
- アクセス制御
- ネットワークの保護
- コンプライアンスの管理
- 監視
- インシデントへの対応。
SentinelOne Singularity Cloud Workload Security (CWS) プラットフォームはコンテナセキュリティにおいて重要な役割を果たします。コンテナ化されたアプリケーションをライフサイクル全体を通じて保護します。このプラットフォームは、ランタイム保護を自動化し、脆弱性を処理し、コンプライアンスを強制します。Kubernetes やその他のシステムと連携して、パブリッククラウドとプライベートクラウドの両方でコンテナをリアルタイムに可視化し、保護します。
コンテナセキュリティライフサイクルには5つの主要なステップがあります：
- イメージセキュリティ：安全性が確認されたイメージから始め、頻繁にチェックして脆弱性を発見します。
- ビルド時のセキュリティ: コンテナのビルドプロセスが安全なルールと方法に従っていることを確認します。
- デプロイ時のセキュリティ:コンテナを展開する際は、安全ルールを適用し、必要な最小限の権限のみを付与し、安全なネットワークを設定する。
- 実行時セキュリティ:コンテナの異常な動作を監視し、実行時の安全ルールを適用し、ネットワークを分離する。
- 廃止:コンテナの使用を停止する際は、すべての個人データを確実に消去する。
