コンテナセキュリティとは、コンテナ化されたアプリケーションやワークロードを保護するためのメカニズムやプロセスを実装することを指します。今日のクラウド環境では、コンテナホストのロケーション、実行中または停止中のコンテナの特定、CISベンチマークに準拠していないコンテナホストの検出、脆弱性評価の実施といった側面を最大限に可視化することが重要となります。
「コンテナ」とは具体的に何でしょうか。Google Cloudはコンテナを、アプリケーションコードにソフトウェアサービスを実行する上で必要な特定バージョンのプログラミング言語ランタイムやライブラリなどの依存関係を加えた軽量のパッケージと定義しています。Kubernetesのようなコンテナオーケストレーションプラットフォームは、イメージの開始、停止、メンテナンスに加え、プロビジョニングの自動化という大きな役割を担っています。
コンテナオーケストレーションはKubernetesなどのツールで抽象化・自動化されるため、CI/CD（継続的インテグレーションまたは継続的デプロイメント）ライフサイクルに統合する上で適しており、DevOpsプラクティスを採用する上で重要な要素となります。このプロセスは、新しいアプリケーションやコードの更新を効率的かつ高信頼性で配信する方法のため、問題が発生しないようガードレールが必要となります。コンテナの観点からは、以下を行う必要があります。
速度を向上させる要素を導入する際には、その過程でセキュリティと制御の精度が落ちるリスクが常にあるため、セキュリティチームは開発組織の担当者と協力して、適切なガードレールとチェックが行われていることを確認する必要があります。
コンテナセキュリティは、アプリケーションのリスクを早期に明らかにし、開発プロセスの摩擦をできるだけ減らすため、CI/CDパイプラインをできるだけ早い段階で実装する必要があります。
クラウドワークロード環境でのテクノロジーの運用は複雑なため、コンテナセキュリティは重要です。コンテナは、今日のパブリックインターネットに接続されたアプリケーションの多くが構築される基盤となります。そのため、コンテナセキュリティがおろそかになると、アプリケーションがさまざまなリスクにさらされることとなります。デジタル資産のコンテナ化に伴うリスクは管理可能で、以下の方法で軽減できます。
コンテナ運用の概要と近年コンテナ運用への注目が高まる理由を理解できたところで、これらの環境を保護するためのベストプラクティスを導入する方法を見てみましょう。
定常状態のコンテナとイメージのスキャンだけでなく、コンテナが動作している実行時にもセキュリティを実装することが重要です。セキュリティは継続的に行われ、開発時にセキュリティを完全に保証できません。そのため、問題がある場合に修正が可能かつ行われるべきタイミングは、デプロイメント後となります。
CI/CD環境では、常に脆弱性が発生する可能性があります。何か月も発見されないままの脆弱性が突如現れることもあります。デプロイメントと更新を定期的に行う場合、セキュリティチームが可能な限りすべての脆弱性を発見できるようにすることが重要です。コンテナセキュリティプログラムの脆弱性特定を目的として、定期的にスキャンを行うことが不可欠です。コンテナイメージのスキャンでは通常、公開されている脆弱性のリストを含む脆弱性とエクスプロイトのデータベースを参照します。
インフラストラクチャは細分化が進んでより一時的なものとなり、物理マシンでなくコードへの依存度が高まっています。そのため、コンテナの脆弱性の監視は、システムの健全性において非常に重要な役割を果たします。すべてのテストを行い、合格しても、デプロイメント後のテストで問題が発生する可能性もあるため、CI/CDパイプライン全体で一貫したセキュリティチェックを備えたソリューションを使用することが非常に重要となります。これにより、チームはデプロイメントを遅らせずに誤設定やポリシー違反を修正できるようになります。
仮想世界での運用開始という決定は、DevOps組織にとって転換点となるもので、コンテナには多数のメリットがあります。企業がそうしたインフラストラクチャに投資する際は、アプリケーション層に至るまでインフラストラクチャを保護し、コンテナのプロビジョニングの標準方法を設定することをお勧めします。重要なコンテナイベントをリアルタイムで監視、追跡することで、アプリケーションのパフォーマンス最適化につなげられます。このプロセスを完成させるには、実行中のすべてのコンテナに対し、CPU、メモリ、ネットワーク使用量などのリアルタイムのパフォーマンス監視と分析を活用することが最善です。
他のクラウドリソースと同様に、コンテナとその内部で実行されるプロセスには、IDおよびアクセス管理(IAM)プランで、できれば 最小特権アクセス(LPA) に従って追跡および管理する必要があるロール/権限が割り当てられます。DevSecOps組織が新しいマルチクラウドコンテナ環境を調整した後は、アクセスを必要な人だけに制限する必要があります。IAMは、クラウドとコンテナのサービスをセキュアでコンプライアンスの高いものにするための鍵です。 また、境界の流動性と、大規模なクラウド環境を管理するという大きな課題に対処するための合理的で持続可能なアプローチを確立するのにも役立ちます。
顧客はクラウドサービスプロバイダ（CSP）との契約時にベンダーを選択でき、コンテナランタイムやコンテナオーケストレーションプラットフォームの選択肢は多岐にわたります。ただし、CSPによりコンテナ管理製品は複数あることを考慮しつつ、基盤となるクラウドプラットフォームで適切なサポートがあるソリューションを選択することが重要です。
Dockerは2013年に市場投入された製品で、コンテナでアプリケーションをパッケージ化して実行する機能を提供します。このプラットフォームにより、ユーザーが作業中にコンテナを共有できるようになり、全員が同じコンテナと機能を表示して操作できるようになります。開発、配布、テスト、デプロイメントを通じたコンテナのライフサイクル管理に役立ちます。
Kubernetesは、ワークロードとサービスを管理するためのオープンソースのコンテナオーケストレーションプラットフォームです。Kubernetesはコンテナのデプロイメントを担当し、コンテナが相互に通信できるようにするソフトウェア定義ネットワーキング層も管理します。移植性があるプラットフォームで、宣言的な構成と自動化を容易にします。Googleは2014 年にKubernetesプロジェクトをオープンソース化しました。
Google Kubernetes Engine（GKE）は、2018年リリースのDockerコンテナを実行するクラスターマネージャー・オーケストレーションシステムで、オンプレミス、ハイブリッド、パブリッククラウドのインフラストラクチャと連携し、仮想マシンのコンテナクラスタを管理して迅速にデプロイできます。GKEは、宣言されたコンテナをその通りにスケジュールし、アプリケーションをアクティブに管理できます。
Amazon Elastic Container Service（ECS）は2014年に提供開始されたサービスで、AWSプラットフォームの他の部分と統合してクラウドとオンプレミスでコンテナワークロードを実行するよう設計されています。ECSは、環境全体で一貫したツール、管理、ワークロードのスケジューリングとモニタリングを提供します。ユーザーは、リソースのニーズと可用性に応じて可用性ゾーン全体でアプリを自動的にスケーリングしたり、コンテナを自由に配置できます。
簡単に説明しましたが、これらのクラウドコンテナ環境の舞台裏は複雑になる可能性があります。近年のプロバイダが使いやすさを最優先する中、複雑さのほとんどはバックグラウンドに追いやられていますが、ユーザーがこうした環境をセキュリティで保護するという課題を意識する必要は依然としてあります。セキュリティを修正する方法を知るためには、その仕組みをまず押さえるべきです。コンテナのセキュリティに関する一般的な課題をいくつか見てみましょう。
2022年クラウド誤設定レポート：最新のクラウドセキュリティ侵害と攻撃の傾向