コンテナセキュリティとは、組織のインフラをサイバー攻撃から守ると同時に、コンテナを脅威から守り、セキュアな環境で運用するためのツール活用とポリシー設定のプロセスを指します。 コンテナを保護することが重要である理由は、ネットワークやアプリケーションを保護することが重要である理由と同じです。
コンテナセキュリティは、インフラストラクチャやランタイムはもちろん、コンテナイメージの作成から本番稼働、運用までのビルドパイプライン全体を保護することが重要です。
この点を考慮すると、コンテナセキュリティはビルドパイプラインに組み込むことになります。開発プロセスに統合し、CI/CDパイプライン同様、セキュリティも自動化して手動のタッチポイントを減らし、基礎となるインフラストラクチャのメンテナンスや運用と統合する必要があります。そして、ビルドパイプラインのコンテナイメージと、ランタイムホスト、プラットフォーム、アプリケーションレイヤーを保護します。継続的デリバリーライフサイクルの一部としてセキュリティを実装すると、コンテナ環境全体でリスクが軽減され、脆弱なポイントが減少します。
以下に、コンテナを保護する際の主な懸念事項を示します。
コンテナのニーズを満たすために使用しているサービスには、Docker®、Kubernetes®、Amazon Web Services™ (AWS)、およびMicrosoft®のようなブランド名が使われています。
コンテナの保護を開始する前に、コンテナ業界の主要サービスについて知っておく必要があります。コンテナ市場のリーダーであるDockerは、アプリケーションを構築、管理、保護するためのコンテナプラットフォームを提供しています。従来のアプリケーションから最新のマイクロサービスにいたるまで、Dockerを使えばどこにでもそれらをデプロイできます。Dockerを利用している際も、他のコンテナプラットフォームと同様に、その特性を踏まえて適切な保護を実装する必要があります。詳細については、「Dockerコンテナセキュリティ」をご覧ください。
次に知っておくべきサービスはKubernetesです。Kubernetesは、コンテナ化されたアプリケーションの管理、デプロイなどを自動化するためのプラットフォーム（コンテナオーケストレーションツール）です。Kubernetesはセキュリティ機能を備えていますが、セキュリティを維持するための専用のセキュリティソリューションが必要になります。昨今では、Kubernetesクラスタへの攻撃が増加しています。詳細については、「Kubernetesの保護」をご覧ください。
次はAWSです。AWSは、エンジニアがアプリケーションをより迅速に開発できるようにするため、コンテナを利用した、スケーラブルで高パフォーマンスのコンテナマネージドサービス、Amazon Container Service (Amazon ECS)を提供しています。このサービスは、Dockerコンテナをサポートし、独自の仮想マシンとコンテナ環境を管理する必要がなく、コンテナ化されたアプリケーションをAWS上で簡単に実行およびスケールできるようにします。このサービスのメリットを最大限に享受するには、コンテナの特徴を踏まえたセキュリティの実装が必要です。
そしてMicrosoftはMicrosoft Azure Container Instances(ACI)を提供しています。このソリューションは、開発者が基礎となるインフラストラクチャを実行または管理することなく、Microsoft® Azure™ Public Cloud上にコンテナをデプロイすることを可能にします。Microsoft® Azure™ ポータルを使って新しいコンテナをスピンアップするだけで、基礎となるコンピュータリソースをMicrosoftが自動的にプロビジョニングし、拡張します。Azure Container Instancesを使用すると、優れた速度と俊敏性を実現できますが、すべてのメリットを問題なく享受するためには、Azure Container Instancesを保護する必要があります。
詳細については、「Microsoft Azure コンテナインスタンスの保護」をご覧ください。
ホストの保護は、ホストを実行するOSを選択するところから始まります。可能な場合には常に、コンテナを実行するために最適化されたオペレーティングシステムを使用してください。Linux®ストックディストリビューションまたはMicrosoft® Windows®を使用している場合は、不要なサービスを無効にするか削除し、オペレーティングシステムを全体的に強化するようにしてください。その後、セキュリティツールと監視ツールを追加して、ホストが予期したとおりに動作していることを確認します。この状況では、アプリケーションコントロールや侵入防御システム（IPS）のようなツールが非常に有用です。
運用環境で動作するようになったら、コンテナは他のコンテナやリソースと情報をやり取りするようになります。コンテナからのネットワークトラフィックがすべてIPSを通過するようにして、この内部トラフィックを監視、保護する必要があります。そのためには、従来のような大規模なIPSエンジンをネットワーク境界に設置するのではなく、各ホストにIPSを設置するよう、セキュリティの実装方法をコンテナ環境に最適化する必要があります。こうすることで、コンテナ環境の特徴を踏まえて、すべてのトラフィックを効果的に監視できます。
運用環境で稼働するようになると、コンテナは、アプリケーションのデータの処理、ログファイルの生成、ファイルのキャッシュなどを常に実行します。これらが通常のアクティビティであり、不正なものではないことを保証する必要があります。コンテナ内のコンテンツに対して実行されるリアルタイムの不正プログラム対策が成功には不可欠です。
IPSはここでも、仮想パッチと呼ばれる利用方法で役割を果たします。脆弱性が公開された場合、IPSエンジンはそれを悪用しようとする試みを検知し、パケットを削除して、アプリケーションを保護します。これにより、緊急修正プログラムを適用する代わりに、そのコンテナの次バージョンで根本原因を解決するために必要な時間を稼ぐことができます。
アプリケーションをコンテナにデプロイする際は、ランタイムアプリケーション自己保護（RASP）が役立ちます。この実装方法の場合、セキュリティは、アプリケーションコード内で実行され、コード内の主な呼び出しをインターセプトまたはフックします。SQLの監視、依存関係のチェックと修復、URLの検証などのセキュリティ機能に加え、RASPは、根本原因の特定という、セキュリティにおける最大の課題の1つも解決します。
これらのセキュリティは、アプリケーションコード内に配置されるため、セキュリティの問題と、その問題を引き起こしたコード行との間にある点と点を結び付けるのに役立ちます。
セキュリティの観点から見ると、複数のコンテナを調整するための管理スタックは見過ごされがちです。コンテナのデプロイに取り組む組織は、プロセスを管理するために役立つ2つの重要なインフラストラクチャ（Amazon ECSなどのコンテナレジストリとKubernetes）を組み合わせて、コンテナのデプロイを調整する必要があります。
レジストリを使用すると、コンテナの共有を簡素化し、各チームがリソースを有効活用できます。ただし、各コンテナが開発およびセキュリティのベースラインを確実に満たすようにするには、自動化された検索ツールが必要です。既知の脆弱性、不正プログラム、および意図せず公開してしまう機密事項がレジストリで参照可能になる前に、これらを各コンテナイメージで検索することで、ダウンストリームの問題を削減できます。
さらに、レジストリ自体が適切に保護されていることが重要です。これは、強化されたシステムまたは非常に信頼性の高いクラウドサービスで実行する必要があります。クラウドサービスにおいても、共有責任モデルを理解し、役割ベースの強力なレジストリアクセスアプローチを実装する必要があります。
オーケストレーションの面では、Kubernetesが環境内で実行およびデプロイされれば、チームが環境を最大限に活用するために役立つ多くのメリットが提供されます。また、Kubernetesでは、Pod(クラスタレベルのリソース)やネットワークセキュリティポリシーなど、運用やセキュリティに関する多数のコントロールを実装できるため、リスク許容度を満たすさまざまなオプションを適用できます。
構成要素として使用したコンテナが、信頼性が高く、一般的な脅威に対して安全であることを確認するには、コンテナイメージのセキュリティを導入する必要があります。このタイプのツールは、コンテナイメージ内のコンテンツを検索し、それらがアプリケーションの構成要素として使用される前に問題を特定するとともに、コンテナが運用環境に展開される前に一連の最終チェックを実施します。
適切に実装すると、検索は自然とコーディングプロセスの一部になります。これは完全に自動化されたプロセスで、これによってアプリケーションとそのコンテナの開発時に発生した問題をすばやく容易に特定することができます。
攻撃者は、その攻撃を継続的統合/継続的デリバリー（CI/CD）パイプラインの初期段階にシフトし始めています。ビルドサーバやコードリポジトリ、開発者ワークステーションの侵害に成功すれば、攻撃者は環境内にはるかに長くとどまることができるからです。常に最新状態が保たれた一連の強力なセキュリティ実装が必要です。
コンテナを保護するには、包括的なセキュリティアプローチが必要です。組織内の他のチームのニーズに対応していること、およびアプローチを自動化してDevOpsプロセスに適合できることを確認するとともに、納期を満たし、アプリケーションを保護しながら迅速に提供できることを確認する必要があります。もはやセキュリティを傍観者のような存在、あるいは土壇場になって現れてワークフローの変更を迫るような存在として扱うことは許されません。信頼できるセキュリティと自動化されたプロセスを最初から構築することにより、セキュリティ上の懸念に対処し、チーム間のギャップを容易に解消することができます。