コンテナセキュリティ管理のベストプラクティスの実装

Docker と Kubernetes テクノロジーの成熟に伴い、コンテナは現在最も注目されている開発コンセプトの 1 つになっています。これはクラウド ネイティブ コンセプトの重要な部分であり、クラウド ネイティブ エコシステムでコンピューティングとワークロードを展開するための唯一の選択肢になりつつあります。 Cloud Native Computing Foundation (CNCF) の最新のクラウド ネイティブ調査によると、96% の組織がコンテナーと Kubernetes を積極的に使用または評価しています。ご存知のとおり、コンテナはアプリケーションのパッケージ形式として、軽量かつ低コストで実行でき、移植性、一貫性、高効率性などの利点がありますが、セキュリティ上の問題がないわけではありません。

コンテナのセキュリティ保護は、サイバーセキュリティと同様に、人、プロセス、テクノロジーの組み合わせを必要とする複雑な作業であり、人間のセキュリティが最も重要です。コンテナへの移行を検討している組織にとって、クラウドネイティブ運用モデルのセキュリティを確保するために、既存のスタッフのスキルを向上させ、必要なスキルを持つ追加の人材を採用することが重要です。以下は、コンテナの脆弱性リスクを管理するためのベスト プラクティスと関連ツールです。企業がこれらのツールを採用し、ベスト プラクティスを実装し、業界のベスト ガイダンスに従えば、コンテナの安全な使用という点で理想的な状態に近づくことができます。

コンテナセキュリティとクラウドセキュリティの緊密な連携

まず、クラウド環境におけるコンテナの役割と関係を理解する必要があります。クラウド ネイティブ エコシステムには通常、クラウド セキュリティに関連するクラウド、クラスター、コンテナー、コードが含まれます。各レイヤーは次のレイヤーの上に構築され、あるレイヤーのセキュリティが不安定になると、その下のレイヤーにも影響が及びます。たとえば、安全でないコンテナにデプロイされたアプリケーションは、コンテナの影響を受けます。クラウド、Kubernetes クラスター、またはアプリケーション自体の脆弱性は、それぞれ独自の問題を引き起こす可能性があります。コンテナが存在する状態 (イメージや実行中のコンテナなど) や、コンテナ内に配置される可能性のあるレイヤーとコードの数を考えると、コンテナのセキュリティを確保するのは決して簡単ではありません。 CNCF のホワイト ペーパー「クラウド ネイティブ セキュリティ」は、読者がクラウド ネイティブ アプリケーション、コンテナー、およびそのライフサイクルをより深く理解するのに役立ちます。

コンテナのポータビリティ保護の強化

コンテナの最も顕著な利点の 1 つは携帯性ですが、それは欠点でもあります。脆弱性がコンテナに混在して配布されると、その脆弱性はイメージを使用するすべてのユーザーに配布され、通常はマルチテナント アーキテクチャで実行されるため、コンテナが実行される環境が危険にさらされる可能性があります。つまり、広く利用可能で共有されているコンテナ イメージは、オープン ソース コードや IaC などの他の問題と同様に懸念されるものであり、これらはすべて脆弱性をもたらす可能性があります。さらに、コンテナは従来の IT チームではなく外部の開発者によって構築され、その後企業に配布されることがよくあります。この文脈では、最善の安全なプログラミングとコンテナ セキュリティ プラクティスを実装することが良いスタートとなります。

コンテナの脆弱性をタイムリーにスキャンする

セキュリティのシフトレフト運動の一環として、パイプラインの展開アクティビティ中にコンテナをスキャンする必要があります。現在、基本的なプラクティスとしては、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインでコンテナをスキャンして、脆弱性がランタイム実稼働環境に侵入するのを防ぐことが挙げられます。パイプライン内のコンテナの脆弱性を発見することで、その脆弱性が本番環境に導入され、犯罪者に悪用されるのを防ぐことができます。これは、実稼働環境で脆弱性を修正するよりも効率的で、リスクが少なく、コストもかかりません。市場には、Anchore や Trivvy などのオープンソース ツールのほか、Snyk などの主流のセキュリティ ベンダーが提供する商用ツールもあります。

ただし、パイプライン内のコンテナ イメージをスキャンすることは万能薬ではありません。コンテナ イメージはリポジトリに保存され、本番環境にデプロイされると有効になることが多いため、両方の環境でイメージをスキャンすることが重要です。新しい脆弱性は頻繁に出現するため、以前にスキャンしたイメージをリポジトリからプルして再スキャンせずにデプロイするだけでは、前回のスキャン以降に公開された新しい脆弱性を見逃してしまう可能性があります。実稼働環境の脆弱性についても同様です。企業のアクセス制御メカニズムが不十分で、実行中のコンテナに変更が加えられた場合、脆弱性が簡単に発生する可能性があります。そのため、稼働中のコンテナの脆弱性を特定し、関係する従業員に通知して、調査と介入のための適切な対応を行う必要があります。

コンテナイメージ署名の使用

コンテナ ワークロードを保護するためのもう 1 つの重要なアクティビティは、イメージの署名です。 CIA のサイバーセキュリティの 3 つの要素である機密性、完全性、可用性は誰もが知っています。コンテナ イメージ署名は主に、コンテナ イメージの整合性を確保するために使用されます。使用されるコンテナ イメージが改ざんされておらず、信頼できるものであることを保証します。これはレジストリ内で、または DevOps ワークフローの一部として実行できます。

コンテナ イメージに署名するためのツールはいくつかあります。最も注目すべきツールの 1 つは Cosign です。これは、イメージの署名、検証、およびストレージをサポートし、ハードウェア、キー管理サービス (KMS)、組み込みの公開キー インフラストラクチャ (PKI) などのさまざまなオプションをサポートします。現在、Chainguard などの革新的なチームに好まれるキーレス署名オプションも市場で入手可能です。キーレス署名は、実際には、署名アクティビティ中にのみ有効で、ID に関連付けられた短命キーを使用する機能をサポートしています。

コンテナイメージのソフトウェアコンポーネントをインベントリする

コンテナにはソフトウェア サプライ チェーンのセキュリティ問題もあり、多くの組織がコンテナ イメージのソフトウェア部品表 (SBOM) を作成しています。 Anchore の Syft ツールは良い例です。 Syft を使用すると、組織は CI/CD ワークフローの一部としてコンテナ イメージの SBOM を作成できるため、コンテナ エコシステムで実行されているソフトウェアに関する洞察を得て、潜在的なセキュリティ インシデントに備えることができます。

以前は、このような高い視認性を得るのは困難でしたが、現在は状況が異なります。多くの組織はソフトウェア サプライ チェーンのセキュリティを重視しており、サイバーセキュリティに関する大統領令など、ホワイト ハウスや関連政府機関のガイダンスに従っています。同時に、安全な開発手法に重点を置くよう求める声が高まっており、NIST などの組織は、ソフトウェア バージョンのアーカイブや保護などの活動で SBOM を使用することを組織に義務付ける Secure Software Development Framework (SSDF) の更新バージョンをリリースしています。この文脈では、ソフトウェア サプライ チェーン内のコンポーネントは高い可視性を誇ります。

コンテナ イメージの SBOM をリストすることに加えて、企業は証拠も提供する必要があります。 NIST は、「ソフトウェア サプライ チェーン セキュリティ ガイド」に該当する規制を定めています。 NIST では、SSDF の認証を受けるための作業が必要であり、そのためには SBOM を使用する必要があります。 in-toto 仕様を使用して SBOM 証明をサポートし、SBOM をさらに実装するための革新的なソリューション (Syft など) もあります。この証明方法により、署名者は SBOM がコンテナ イメージの内容を正確に表していることを証明できます。

参考リンク: https://www.csoonline.com/article/3656702/managing-container-vulnerability-risks-tools-and-best-practices.html