コンテナセキュリティに関する初心者向けガイド

現代のソフトウェア開発においては、リソース効率と可動性に優れたコンテナを選ぶ機会がますます増えています。実際、市場調査会社であるGartner社によると、コンテナ化されたアプリケーションを2つ以上運用する組織は2023年までに70%以上に達すると予想されています。

しかし、コンテナには特にセキュリティに関するデメリットがあります。GitLabの2022年グローバルDevSecOps調査では、コンテナに対するセキュリティ戦略を掲げているセキュリティ担当者は64%しかおらず、多くのDevOpsチームはその他の最新ソフトウェアテクノロジー（クラウドネイティブ、Serverless、API、マイクロサービスなど）に対する戦略を持ち合わせていないことが明らかになりました。

DevOpsチームが採用すべきソリューションは、セキュリティ対策をシフトレフト（早期化）し、ソフトウェア開発プロセスの各ステージに組み込むことです。この記事では、このような目標を達成するためのロードマップをステップごとに解説します。

コンテナとは、アプリケーションの実行に必要なすべてのコンポーネント（アプリケーションコード、ランタイム、ライブラリ、構成など）を包括する、軽量化されたユニットのことです。また、コンテナセキュリティとは、安全と完全性を確保することを目的としたセキュリティ関連の措置や対策を指します。コンテナセキュリティは、コンテナ内のアプリケーションをはじめ、それらが実行されるインフラストラクチャにいたるまで、すべての要素を網羅します。すべてのイメージが信頼できるソースから派生したものであることを保証するためには、ベースイメージのセキュリティと品質を確保することが不可欠です。コンテナパイプラインのセキュリティ対策として、信頼できるイメージの収集、プライベートレジストリを使用したアクセスの管理、セキュリティテストの統合、デプロイの自動化、そしてインフラストラクチャの継続的な保護に取り組みましょう。コンテナの強化とは、コンテナスキャンツールを使用して潜在的な脆弱性を検出し、攻撃に遭うリスクを最小限に抑えるプロセスを指します。

コンテナセキュリティを強化することで、セキュリティフロー（セキュリティ上の欠陥）や悪性コードを含むコンテナが本番環境にデプロイされるリスクを軽減できます。

コンテナセキュリティは従来のセキュリティ手法とは異なります。これは、コンテナ環境が複雑で動的な特性を持っているためです。簡単に言えば、移動するコンポーネントがはるかに多く、さまざまなセキュリティリスクが存在します。

コンテナは、小さな仮想マシン（VM）のように使用できると思われがちですが、実際にはそうではなく、異なるセキュリティ戦略を必要とします。コンテナ内のアプリケーション間のトラフィックは、境界ネットワークセキュリティを通過することはないものの、アプリケーションとそのイメージの間の悪質なトラフィックを監視する必要があります。オーケストレーターを使用してプロセスとリソースに関するセキュリティポリシーを設定できますが、これだけでは包括的なセキュリティ戦略を確立できません。

コンテナイメージとは、各コンテナで実行するコンポーネントを定義したものです。デベロッパーは、イメージにセキュリティ上の脆弱性や不正なコードが含まれていないことを確認するとともに、コンテナのアタックサーフェスを最小限に抑えるために、不要なイメージを作成しないようにする必要があります。信頼できないイメージを禁止するために、イメージ検証ツールを使用できますが、デフォルトでは有効になっていないことがよくあります。また、脆弱性のリスクを含んだ依存関係を持つイメージを検知するために、ビルド済みのイメージをスキャンすることもできます。

VMとは異なり、コンテナは複数まとめて同じオペレーティングシステム（OS）上で実行でき、各レベルで攻撃リスクを伴います。脆弱なホストOSはコンテナを危険にさらし、さらにコンテナに脆弱性があると、ホストOSへの攻撃経路となってしまう可能性があります。ネームスペースの分離を実施して、コンテナとホストOSカーネル間のトラフィックを制限し、ベンダーパッチ配信に合わせてパッチの適用を自動化することが重要です。また、不要なコンポーネント（オーケストレーターの実行に必要ないアプリケーションやライブラリなど）を排除し、OSの無駄を最小化する必要があります。

コンテナオーケストレーションとは、コンテナの調整と管理を行うことです。これにより、コンテナ化されたアプリケーションをスケールして数千人のユーザーをサポートできます。オーケストレーターには、独自のセキュリティ機能がビルトインされていることがあります。これらの機能を使用して、クラスター内のすべてのポッドに自動適用されるKubernetesのルールを作成できる可能性があります。こうした基本機能の活用は有効であるものの、より強力なポリシーを設定するための第一歩に過ぎません。

コンテナは複数のシステムやクラウドプロバイダーに配置される可能性があるため、アクセス管理が非常に重要になります。コンテナへのアクセスを特権ユーザーに限定するために、APIキーやログイン認証情報、トークンなどのシークレットを厳格に管理する必要があります。また、ユーザーによるアクセスをロールに基づいて制御することもできます。これは、必要に応じてアクセスを制限したい場合に有効です。

デプロイ後は、コンテナアクティビティをモニタリングし、チームがセキュリティ上の脅威を検出して対処できるようにする必要があります。Nordcloud社は、ネットワーク呼び出し、APIコール、異常なログイン試行などの不審な行動をモニタリングすることを推奨しています。チームは、ポッドに対する対処手順をあらかじめ定義し、対象のコンテナを別のネットワークに隔離するか、再起動するか、もしくは脅威が特定されるまで停止できる体制を整えておく必要があります。これにより、マルウェアに対するセキュリティ体制をさらに強化できます。

クラウドプロバイダーは、クラウドサービスの提供にあたり、基盤となるハードウェアや基本的なネットワークのセキュリティ対策を担います。しかし、こうした対策に加え、アプリケーションのアクセス管理、アプリケーションの設定とパッチ適用、システムのパッチ適用とアクセス管理などの措置は、ユーザーにも委ねられています。

2017年、米国商務省はアプリケーションコンテナセキュリティガイド（英語）を公開しました。このガイドが公開されてからすでに数年が経っているものの、以下の推奨事項はコンテナを最近導入したチームにとって今でも有用な情報です。

• **コンテナを活用してアプリケーションの開発、実行、サポートの手法を革新するために、組織の運用体制と技術プロセスを最適化する。**コンテナの導入にあたり、既存の文化や開発手法に混乱が生じる場合や、コンテナ化された環境に既存のアプローチを直接適用できないことがあります。コーディング手法や運用方法を見直すよう、チームを奨励し、教育やトレーニングを提供しましょう。

• **アタックサーフェスを縮小するために、汎用的なホストOSではなく、コンテナ専用のホストOSを使用する。**コンテナ専用のホストOSとは、コンテナのみを実行するよう設計された最小限のOSを指します。専用のホストOSを使用することで、アタックサーフェスを大幅に縮小し、コンテナが危険にさらされるリスクを低減できます。

• **目的や機密性、脅威の状況が同じコンテナのみを単一のホストOSカーネル上にまとめて、より高度な保護体制を確立する。**コンテナを分類することで、より高度な保護体制を整えられます。このようにコンテナをグループ化することで、攻撃者による他のグループへの侵入リスクを軽減できるほか、より高い確率で侵入を検知し、封じ込められます。

• **セキュリティ侵害を回避するために、イメージの脆弱性管理にはコンテナ専用のツールとプロセスを採用する。**従来のツールでは、コンテナ化されたモデルとの整合性が取れず、コンテナ内の脆弱性を検出できないことがよくあります。組織は、イメージの構成を安全に保つためのベストプラクティス（レポートの一元管理、各イメージのモニタリング、準拠していないイメージの実行の防止など）へのコンプライアンスを検証し、実施するためのツールとプロセスを採用する必要があります。

• **信頼性の高いコンピューティング基盤を確立するために、ハードウェアベースの対策を行うことを検討する。**信頼されたプラットフォームモジュール（TPM）のようなハードウェアの信頼の基点に基づいてセキュリティを確立することで、コンテナテクノロジーのすべてのティアにセキュリティ対策を拡張します。

• **コンテナ対応のランタイム防御ツールを使用する。**コンテナ環境をモニタリングし、異常で悪意のあるアクティビティを正確に検出できるコンテナセキュリティ専用のツールを導入および運用します。

専門用語を学んで、実践してみましょう。

DevSecOpsセキュリティの基礎知識を習得しましょう。

GitLabを利用してDevSecOpsを開始しましょう。