本文の内容は、2022年4月7日現在における、Sysdig Cloud Native Learning Hub上のWhat Is Container Security?(https://sysdig.com/learn-cloud-native/container-security/what-is-container-security/) を元に日本語に翻訳・再構成した内容となっております。
コンテナセキュリティは、コンテナライフサイクルのすべての段階において、マルウェアやデータ漏洩などの脅威からコンテナを保護するプロセスです。コンテナイメージのビルドから、レジストリへのロード、本番環境へのデプロイまで、コンテナを潜在的な脅威から保護するためのツールやプロセスを実装する必要があります。
この記事では、コンテナライフサイクル全体にわたるコンテナセキュリティの管理について知っておく必要があるすべてのことを説明します。
コンテナセキュリティに対する一般的な脅威
コンテナセキュリティを理解するには、コンテナに影響を与える可能性のあるセキュリティの脅威を理解することから始まります。これらの脅威は、ここで詳しく説明することができないほど多くの形態で現れます。しかし、最も一般的なコンテナセキュリティの脅威には、次のようなものがあります。
コンテナマルウェア
マルウェアは、コンテナ内にデプロイされる悪意のあるコードです。マルウェアは、コンテナライフサイクルのさまざまな段階でコンテナに潜り込むことができます。たとえば、CI/CD環境を侵害する攻撃者は、後にコンテナイメージをビルドするために使用されるソースコードリポジトリにマルウェアを挿入する可能性があります。また、攻撃者は、コンテナレジストリに侵入し、マルウェアを含む汚染されたイメージに置き換える可能性があります。コンテナ型マルウェアの3つ目のタイプは、ユーザーを騙して、外部ソースから悪意のあるコンテナイメージをダウンロードさせるという攻撃です。いずれの場合も、コンテナの起動前に検出されなかったマルウェアがランタイム環境に侵入し、アプリケーションから機密データを収集したり、他のコンテナを妨害したりするなど、さまざまなセキュリティ上の問題を引き起こす可能性があります。
安全でないコンテナ特権
通常、コンテナは非特権モードで実行されるべきです。つまり、コンテナ化された環境の外側にある、自分が直接制御するリソースにアクセスすることはできないのです。コンテナ間の通信も、コンテナ同士が通信する理由がない限り制限する必要があります（たとえば、アプリケーションコンテナからログを収集するサイドカーコンテナを実行している場合など）。コンテナが厳密に必要とされる以上の特権で実行されると、セキュリティリスクが生じます。安全でない特権は、通常、コンテナオーケストレーターの設定に問題があることが原因です。たとえば、Kubernetesによってオーケストレーションされたコンテナは、Kubernetesのセキュリティコンテキストとネットワークポリシーが適切に定義されていない場合、必要以上の特権を持つ可能性があります。
センシティブなデータを含むコンテナ
コンテナはデータを保存するために使用されることを意図していません。しかし、組織がコンテナイメージ内に機密情報を保存するというミスを犯すことがあります。例えば、Vineのソースコードは、Vineがプライベートだと思っていたコンテナレジストリが、一般にアクセス可能であり、ソースコードを含むイメージをホストしていることを誰かが発見したときに、すべて公開されました。(これは、コンテナ時代の比較的早い時期に起こったことで、コンテナイメージの管理に関するベストプラクティスがまだ十分に確立されていない時期でした。このようなミスが発生するのも無理はありません)。コンテナのライフサイクルを通じたセキュリティ管理
このようなリスクを回避するために、企業はコンテナライフサイクルのすべての段階において、コンテナを保護するセキュリティ管理を実施する必要があります。以下では、各ステージの概要と、各ステージでチームが管理すべき脅威の種類を説明します。開発パイプライン
コンテナのライフサイクルは、開発パイプラインから始まります。開発パイプラインは、後にコンテナに組み込まれるコードが生成される場所です。前述のとおり、開発ツールを侵害した攻撃者は、ソースリポジトリに悪意のあるコードを挿入し、いわゆるソフトウェアサプライチェーン攻撃を引き起こす可能性があります。開発者がイメージの構築に使用する前に悪意のあるコードを検出しなければ、そのコードはパイプラインを伝って本番環境に流れ込む可能性があります。
開発ツールにアクセス制御を導入し、最小特権の原則を徹底することは、このリスクを防ぐのに有効です。また、ソースコードをビルドして出荷する前に、マルウェアがないかスキャンすることも有効です。
コンテナイメージ
コンテナイメージとは、コンテナの実行に必要なコードを含むファイルです。イメージはコンテナそのものではなく、実行するコンテナのベースとなる青写真です。したがって、コンテナイメージの内容にマルウェアや機密データが含まれている場合、そのイメージから作成されるコンテナは安全ではなくなります。前述のとおり、マルウェアがコンテナイメージに入り込まないようにするために、内部のソースコードをスキャンする必要があります。
しかし、コンテナイメージにはサードパーティのソースから取り込んだリソースが含まれることが多いため、自社のコードをスキャンするだけでは十分ではありません。また、コンテナスキャナを使用してコンテナイメージ全体をスキャンする必要があります。このスキャナーは、イメージの内容を評価し、安全でないことが分かっているコンポーネントにフラグを立てます。イメージスキャンは、あらゆる種類の脅威を検出できるわけではありませんが（特に、脆弱性データベースにまだ記録されていないカスタムマルウェアは検出を逃れる可能性があります）、既知の脅威の大部分について警告を発することができます。
コンテナレジストリ
コンテナイメージは作成後、通常コンテナレジストリに格納され、そこからユーザーがダウンロードできるようになります。レジストリのセキュリティに対応するために、いくつかのベストプラクティスがあります。まず、許可されたユーザのみがレジストリ内のイメージにアクセスできるように、アクセス制御を実施する必要があります。こうすることで、イメージにプライベートなアプリケーションやデータが含まれている場合に発生する可能性のある、偶発的なデータ漏洩を防ぐことができます。
次に、レジストリを定期的に監査し、どのようなイメージが含まれているかを把握します。古いバージョンのアプリケーションを含む古いイメージは、攻撃対象領域を最小化するために削除する必要があります。
最後に、サードパーティのレジストリからコンテナイメージを使用する場合は、そのソースを信頼できることを確認してください。最も人気のあるパブリックなコンテナレジストリである Docker Hub にあるイメージの半分には、少なくとも 1 つのセキュリティ脆弱性が含まれています。また、攻撃者が意図的に悪意のあるイメージをアップロードし、疑うことを知らないユーザーを引きつけるような名前（mysqlimageやnginxappなど）にしている場合もあります。非公式なパブリックレジストリからイメージを取得することは避け、また、作成した組織に対する信頼度がどの程度であっても、すべてのイメージをスキャンするようにしてください。
コンテナランタイム環境
コンテナ・ライフサイクルの最終段階はランタイムです。これは、レジストリからダウンロードしたコンテナイメージを使用して、コンテナが実環境にデプロイされるときです。ランタイムセキュリティは、コンテナセキュリティの中でも最も複雑な側面の1つです。なぜなら、このセキュリティには複数の動的な仕組みが関わっており、使用するコンテナアプリケーションスタックの種類によって異なる可能性があるためです。しかし、ほとんどの場合、ランタイムセキュリティは、セキュリティの確保に基づいています。
- コンテナランタイム：コンテナランタイムは、コンテナを実際に実行するサーバ上のプロセスです。ランタイムソフトウェアが最新のものであり、既知のセキュリティ脆弱性に対してパッチが適用されていることを確認する必要があります。
- オーケストレーター：コンテナオーケストレーターは、コンテナのデプロイと管理を行います。ほとんどのオーケストレーターは、コンテナの権限を制限してセキュリティリスクを最小限に抑えるためのさまざまなツールを提供していますが、サードパーティの監視および分析ツールを使用して、オーケストレーターレベルでのセキュリティ問題の検出を支援することも必要です。
- ノード：ノードは、コンテナをホストするサーバです。ノードのオペレーティング システム、ユーザー アカウント、ネットワーク設定、およびその他のリソースを保護し、ノード レベルでの違反によって攻撃者がコンテナ環境に影響を与えることがないようにする必要があります。
継続的なコンテナセキュリティ
コンテナのライフサイクルは、循環的かつ継続的なプロセスです。あるアプリケーションのコンテナが実行環境にデプロイされた後、アプリケーションが更新されると、サイクルは新たに始まり、新しいコンテナのセットがパイプラインにプッシュされます。新しいコンテナには、それぞれ新しいリスクが含まれている可能性があります。このように、コンテナセキュリティは決して「set-it-and-forget-it」なものではありません。コンテナのライフサイクル全体にわたってリスクを継続的に監視し、監視ツール、脆弱性データベース、および設定を更新して、環境の進化に合わせてコンテナセキュリティのベストプラクティスを順守し続けなければなりません。