本文の内容は、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のセキュリティ | コンテナオーケストレーションの セキュリティ設計 | コンテナの脅威検出 |
| サプライチェーンセキュリティ | DevSecOpsとは？ | Falcoとは？ |
コンテナセキュリティとは？
コンテナセキュリティとは、コンテナライフサイクル全体にわたりマルウェアやデータ漏洩などの脅威からコンテナを守るプロセスです。具体的にはコンテナイメージのビルド、レギストリへのロード、本番環境へのデプロイメントという各段階でのセキュリティツールやプロセスへの実装が必要です。
コンテナセキュリティの脅威には、コンテナマルウェア、安全でないコンテナ特権、機密データを含むコンテナがあります。これらのリスクを回避するためには、開発パイプライン、コンテナイメージ、コンテナレジストリ、コンテナランタイムといった各ステージでセキュリティ管理を実施する必要があります。
また、一度対策すれば終わりというわけではありません。コンテナセキュリティはリスクを継続的に監視し、環境の進化に合わせて更新し続けなければなりません。そして、常に攻撃をリアルタイムで検知し、対応する必要があります。
関連ページ：コンテナとKubernetesのセキュリティ | Sysdig
コンテナセキュリティの主な脅威
コンテナセキュリティを理解する上で、まず押さえておきたいのがコンテナセキュリティの脅威を理解することです。これらの脅威は、ここで詳しく説明することができないほど多くの形態で現れますが、最も一般的なものとしては以下の３つがあります。
コンテナマルウェア
コンテナにおけるマルウェアとは、コンテナ内に展開する悪意のあるコードのことです。コンテナライフサイクルでは、さまざまな段階で「マルウェアがコンテナに潜り込む可能性」を考えることができます。
たとえば、第三者がCI/CD環境を攻撃する場合、後にコンテナイメージをビルドするためのソースコードリポジトリへ、マルウェアを感染させることがあります。他にもコンテナレジストリに侵入し、マルウェアを含む汚染されたイメージに置き換える可能性も考えられます。ユーザーを騙し、外部ソースから悪意のあるコンテナイメージをダウンロードさせるという手法もあるでしょう。
コンテナ起動前に検出されなかったマルウェアがランタイム環境に侵入した場合、アプリケーションから機密データを収集したり、他のコンテナを妨害したりなど、さまざまなセキュリティ上の問題を引き起こしてしまうことがあります。
被害を防ぐには、しっかりと予防したうえで、万が一侵入されて感染した際にすぐ気づいて対処できるよう、常時稼働する検知ツールを使うのがおすすめです。
安全性が十分ではないコンテナ特権
コンテナでは、十分に安全性が確保されていない特権がセキュリティ脅威になりうることがあります。
通常、コンテナは非特権モードで実行されるべきです。この場合、コンテナ化された環境の外側にある、自分が直接制御するリソースにアクセスできない形となります。コンテナ間の通信も、相互が通信する理由がない限り、制限をかけなくてはなりません。たとえば、アプリケーションコンテナからログを収集するサイドカーコンテナを実行している場合が挙げられます。
もし、コンテナが必要以上の特権で実行されると、セキュリティリスクが発生しやすくなります。安全でない特権は、コンテナオーケストレーターの設定に原因があることが多いです。たとえば、Kubernetesによってオーケストレーションされたコンテナは、Kubernetesのセキュリティコンテキストとネットワークポリシーが適切に定義されていないと、必要以上の特権を持ちやすくなります。
機密情報を含むコンテナ
コンテナ内にセンシティブな機密情報が含まれる場合、それが脅威となってセキュリティの問題が起こることがあります。
そもそもコンテナの用途はデータ保存ではなく、保存を前提とした仕様になっていません。しかし、運用側が「コンテナイメージ内に機密情報を保存する」などのミスをする可能性があります。
例えば、かつてVineのソースコードは、運用側がプライベートだと思っていたコンテナレジストリが、一般にアクセス可能な状態になっていました。そのため、ソースコードを含むイメージをホストしていることを第三者が発見したとき、すべて流出してしまったのです。ただしこちらは、コンテナというものが登場したばかりの黎明期に起きたトラブルです。コンテナイメージ管理のベストプラクティスが十分に確立されていない時期だったため、現在であれば、一般的に確立された適切な手法を採用していれば、このようなミスを招くことは考えづらいです。
ステージ別のコンテナセキュリティ管理の基本
リスクを回避するためには、コンテナライフサイクルの全段階において、コンテナを保護するセキュリティ管理を実施する必要があります。ここでは、各ステージにおけるセキュリティの概要と、各ステージでチームが管理すべき脅威の種類を紹介します。
開発パイプライン
開発パイプラインは、後にコンテナに組み込まれるコードが生成される場所です。コンテナにおけるライフサイクルのスタート地点でもあります。
開発ツールへと侵入した脅威は、ソースリポジトリにマルウェアを感染させ、いわゆるソフトウェアサプライチェーン攻撃を引き起こす可能性があります。もしそういった脅威を、開発側がイメージ構築前に検出できなければ、パイプラインを通じて本番環境が感染する可能性があります。
リスクを防ぐには、開発ツールにアクセス制御を導入し「最小特権の原則」を徹底することが有効です。ソースコードをビルドし出荷する前に、マルウェアがないかスキャンするのもおすすめの対策となります。
コンテナイメージ
コンテナイメージとは、コンテナの実行に必要なコードを含むファイルです。イメージはコンテナそのものではなく、実行するコンテナのベースとなる青写真です。もし仮に、特定のコンテナイメージにマルウェアや機密データが含まれていると、そのイメージから作成されるコンテナは安全ではなくなります。
悪意を持つコードがコンテナイメージに入り込まないようにするためには、定期的に内部のソースコードをスキャンするのが近道です。自社のコードだけをスキャンすればよいわけではありません。コンテナイメージには、サードパーティのソースから取り込んだリソースが含まれることが多く、それがトラブルを招くこともあります。コンテナイメージ全体をスキャンする必要もあるでしょう。
コンテナスキャナーは、イメージの内容を評価し、安全でないと判定したコンポーネントにフラグを立てます。あらゆる種類の脅威を検出できるわけではなく、特に、脆弱性データベースにまだ記録されていないカスタムマルウェアを見落とす可能性があります。とはいえ、既知の脅威の大部分を検出できることから、有効な対策といえます。
コンテナレジストリ
コンテナイメージは作成後、通常コンテナレジストリに格納され、そこからユーザーがダウンロードできるようになる仕様です。レジストリのセキュリティに対応するために、いくつかのベストプラクティスがあります。
許可されたユーザーのみがレジストリ内のイメージにアクセスできる環境を実現するために、アクセス制御を実施する必要があります。こうすることで、イメージにプライベートなアプリケーションやデータが含まれている場合に発生する可能性のある、偶発的なデータ漏洩を防ぐことが可能です。
合わせて、レジストリを定期的に監査し、どのようなイメージが含まれているかも把握します。古いバージョンのアプリケーションを含むものは、攻撃対象領域を最小化するために削除を検討する必要があります。
サードパーティのレジストリからコンテナイメージを使用する場合は、そのソースを信頼できることを確認しましょう。広津使われるコンテナレジストリのDocker Hubにあるイメージの半分には、少なくとも 1 つのセキュリティ脆弱性が含まれています。また、攻撃者が意図的に悪意のあるイメージをアップロードし、疑うことを知らないユーザーを引きつけるような名前（mysqlimage、nginxappなど）にしている場合もあります。非公式なパブリックレジストリからイメージを取得することは避けましょう。また作成者をどんなに信頼していたとしても、すべてのイメージをスキャンしてから使うようにしてください。
コンテナランタイム環境
コンテナライフサイクルでは、ランタイムも忘れずに確認しましょう。レジストリからダウンロードしたコンテナイメージを使用して、コンテナが実環境にデプロイされるときなどに関係します。
ランタイムセキュリティは、コンテナセキュリティの中でも最も複雑な要素のひとつとなります。なぜなら、安全性には複数の動的な仕組みが関わっており、使用するコンテナアプリケーションスタックの種類によって異なる可能性があるためです。
とはいえ基本的に、ランタイムセキュリティは、「セキュリティの確保」に基づいています。
- コンテナランタイム：コンテナランタイムは、コンテナを実際に実行するサーバ上のプロセスです。ランタイムソフトウェアが最新のものであり、既知のセキュリティ脆弱性に対してパッチが適用されていることを確認する必要があります。
- オーケストレーター：コンテナオーケストレーターは、コンテナのデプロイと管理を行います。ほとんどのオーケストレーターは、コンテナの権限を制限してセキュリティリスクを最小限に抑えるためのさまざまなツールを提供していますが、サードパーティの監視および分析ツールを使用して、オーケストレーターレベルでのセキュリティ問題の検出を支援することも必要です。
- ノード：ノードは、コンテナをホストするサーバです。ノードのオペレーティング システム、ユーザー アカウント、ネットワーク設定、およびその他のリソースを保護し、ノード レベルでの違反によって攻撃者がコンテナ環境に影響を与えることがないようにする必要があります。
まとめ
コンテナのライフサイクルは、循環的かつ継続的なプロセスです。あるアプリケーションを含むコンテナが実行環境にデプロイされた後、アプリケーションが更新されると、サイクルは新たに始まり、新しいコンテナのセットがパイプラインにプッシュされます。新しいコンテナには、それぞれ新しいリスクが含まれている可能性があります。
コンテナセキュリティは決して「set-it-and-forget-it（一度設定したら後は忘れて良い）」なものではありません。コンテナのライフサイクル全体にわたってリスクを継続的に監視し、監視ツール、脆弱性データベース、および設定を更新して、環境の進化に合わせてコンテナセキュリティのベストプラクティスを順守し続けなければなりません。