安全なコンテナイメージを確保するための5つのベストプラクティス

本文の内容は、2020年12月29日にSysdig CTO & Founder Loris Degioanni が投稿したブログ(https://sysdig.com/blog/5-best-practices-for-ensuring-secure-container-images/)を元に日本語に翻訳・再構成した内容となっております。

現代のほとんどの組織は、開発プロセスにセキュリティを組み込む時期が早ければ早いほど、本番環境でのアプリケーションの安全性が高まることを理解しています。コンテナ化されたワークロードの場合、アプリケーションのライフサイクル全体を通してコンテナイメージを保護することは、セキュリ ティの重要な部分ですが、多くの組織では、安全なコンテナイメージを確保するための基本的なベストプラクティスにすら従っていません。

コンテナイメージは、アプリケーションの実行単位であり、ライフサイクルのすべての段階でコードがパッケージ化されたエンベロープです。なぜなら、ライフサイクルの早い段階でコンテナイメージの安全性を確保することで、本番環境でのセキュリティ問題のリスクを減らすことができるからです。

しかし、これは、組織が後になってからセキュリティを無視できるということではありません。コンテナは不透明なため、内部を見ることが困難です。攻撃は、まだ特定されていない脆弱性を悪用して、想定していなかった方法で環境にアクセスする可能性があります。コンテナのセキュリティには、適応可能なプロセスと継続的な警戒が必要です。

5つのステップでコンテナのセキュリティを確保する

ここでは、アプリケーションのライフサイクルを通して、コンテナイメージが可能な限り安全であることを保証することに特化した 5 つのベストプラクティスを紹介します。これらは、コンテナ化されたワークロードのセキュリティの最終手段ではなく、むしろ強力なセキュリティ姿勢の基礎となるものです。しかし、安全なコンテナイメージがなければ、真に安全なアプリケーションを持つことはできません。

ここでは、コンテナイメージのセキュリティ姿勢を改善するためのベストプラクティスを紹介します。

ライフサイクルのあらゆる段階でイメージスキャンを組み込む

イメージスキャンは、一回のみ行ってセキュリティリストからチェックを外すことができるものではありません。むしろ、組織は、アプリケーションのライフサイクルの中で可能な限りイメージスキャンを組み込むべきです。これには、以下が含まれます。

• イメージが CI/CD パイプライン内でビルドされているとき
• イメージがrepoにあるとき。
• イメージが実行されているとき

新しい CVE は継続的に発見され、公開されており、昨日までは準拠していたイメージが今日は脆弱性があるかもしれません。レジストリや実行時にイメージを継続的にスキャンすることで、このようなドリフトからの保護を強化することができます。また、実行される環境の感度に応じて、特定の深刻度のCVEを持つイメージをブロックするポリシーによってイメージの実行を制御することもできます。Kubernetesでは、アドミッションコントローラなどの機能を活用することで実現できます。

パイプラインやレジストリ内のインラインスキャンも、より良いセキュリティと制御を提供することができます。これは、イメージの内容やレジストリの認証情報を外部で共有せずに、環境内でローカルにスキャンすることで構成されています。

イメージをルートとして実行しないでください

今年の夏、Sysdigは「2020年コンテナセキュリティスナップショット」を発表しましたが、その結果の中で、イメージの58%がrootとして実行されていることがわかりました。

イメージをルートとして実行することは、開発者にとってアプリケーションを動作させるための最も簡単な方法であることもありますが、フロントドアをロックして隣の窓を大きく開けたままにしておくのと似たようなリスクもあります。イメージが root で実行されている場合、コードの実行が root であることを意味します。root アクセスを持つ攻撃者はコンテナ内で悪意のあるプロセスを実行することができます。カーネルの分離は、攻撃者が root 権限を使ってインフラストラクチャーの他の部分にアクセスすることを防ぎますが、攻撃者がネットワーク経由でそれらのサービスを悪用することを防ぐことはできません（例えば、Nmap を使って脆弱性のあるサービスを特定するなど）。rootアクセス権を持つ攻撃者は、runcのような既知のカーネルの脆弱性を悪用してコンテナのブレークアウトを実行することもできる。

デフォルトでは、コンテナはroot権限で実行されるため、手動で権限を変更するか、コンテナがroot権限を持たないように自動化システムを設置するかは、組織次第である。

root 権限で実行することは危険であり、可能な限り避けるべきですが、実際に起こります。実行時に危険な設定が検出された場合、チームは通常、迅速なデプロイに集中しているため、コンテナを停止しません。その代わりに、猶予期間内に実行し、継続的に監視して、セキュリティポリシーからの逸脱が対処されていることを確認します。

OS と非 OS パッケージの両方をスキャンする

コンテナセキュリティに関するよくある誤解は、オペレーティングシステムパッケージだけをスキャンする必要があるということです。これは真実ではありません。オープンソースであろうと商用であろうと、OSであろうと非OSであろうと、コンテナ内で実行されているすべてのものをスキャンする必要があります。

OS 以外のパッケージもスキャンすることの重要性を強調し、Sysdig は、OS 以外のパッケージの 53% が高レベルまたはクリティカルレベルの深刻度の脆弱性を持っていることを明らかにしました。

起源に注意

パブリックリポジトリから来るイメージは、プライベートリポジトリから来るイメージよりも本質的に安全性が低くなりそうです。例えば、Docker Hubは、約300万個のホスティングされたイメージの1%未満を認証しています。

コンテナイメージには多くのレイヤーがあり、イメージのいずれかのレイヤーに脆弱性が含まれていると、セキュリティ上の問題が発生する可能性があります。公開リポジトリからイメージを取得する場合、誰がそのイメージを作成したのか、そのコンポーネントがどこから来たのか、何もわからないことが多いため、脆弱性が含まれていないことを確認するためには、細心の注意を払う必要があります。

Sysdigの調査によると、イメージの40%は公開ソースから取得しています。

一方で、公開リポジトリの利用を全面的に禁止することは、良いアイデアとは言えません。実際、公開リポジトリからのイメージは、より多くの人の目に触れるため、より安全性が高い可能性があります。要するに、すべてのコンテナイメージ、特にパブリックリポジトリからのイメージを徹底的にスキャンして分析する必要があります。パブリックリポジトリからイメージを取り出す際には、そのイメージをどれだけの人が使っているかに注意を払うことも重要です。3回引っ張ってきたイメージは、2,000万回使用されたイメージよりもはるかにリスクが高くなります。

イメージがどこから来たものであるかに関わらず、タグ付けとバージョン管理をきちんと行うことが重要です。

イメージはできるだけ小さくしましょう

セキュリティを考えると、イメージは小さければ小さいほど良いです。イメージの表面層が小さいほど、イメージを悪用される機会が少なくなります。セキュリティの観点からは、1つのプロセスで実行されるイメージが理想的です。このような状況になることはほとんどありませんが、目標とすべきです。

組織として、必要のないものはイメージを剥ぎ取る作業をしましょう。可能であれば、スタティックリンクを使用し、動的なライブラリや設定ファイルをあまり多く持たないようにしてください。目標は、インシデント発生時にコンテナに関する情報を取得する能力を低下させたり、コンテナの正常な実行を妨げたりすることなく、攻撃の対象となる領域を可能な限り減らすことです。

最終的な目標：安全なコンテナイメージ

セキュアなコンテナイメージは、コンテナ化されたアプリケーションの強固なセキュリティ態勢のために必要な要素ではありますが、十分ではありません。コンテナイメージが可能な限り安全でなければ、アクセス制御やネットワークポリシーなど、クラウドネイティブアプリケーションのセキュリティを確保するために利用可能な他のツールだけでは、悪意のある行為者が被害に遭わないようにするには十分ではありません。残念ながら、ほとんどの組織では、コンテナイメージのセキュリティ保護に十分な注意を払っていません。上記の簡単な手順を踏むだけで、組織のセキュリティ態勢を改善することができます。