本文の内容は、2022年4月21日にDaniella Pontesが投稿したブログPreventing cloud and container vulnerabilities(https://sysdig.com/blog/prevent-cloud-container-vulnerabilities/）を元に日本語に翻訳・再構成した内容となっております。
脆弱性とは、攻撃者に利用される可能性のあるソフトウェアのバグや弱点のことです。脆弱性は、オペレーティングシステム、アプリケーションコード、およびライブラリ、フレームワーク、プログラミングスクリプトなど、サードパーティのコードに依存する部分に存在する可能性があります。Secure DevOpsアプローチを採用し、開発の初期段階で脆弱性を特定することで、アプリケーションの本番稼動が遅れたりして開発者をイライラさせることを避けることができます。したがって、脆弱性のあるワークロードが本番環境に入るのを防ぐことが最も重要ですが、すでに本番環境にあるソフトウェアについても、新たな脆弱性や悪用が発見される可能性があることを念頭に置いてください。脆弱性のスキャンは、ランタイムを含むワークロードのライフサイクル全体を通じて行う必要があります。
コンテナイメージとホストの脆弱性を特定し、ソフトウェア開発ライフサイクルに脆弱性評価とコントロールを統合し、コンテナとホストの脆弱性管理を一元化する方法を紹介します。
コンテナにおける脆弱性の理解
最近のクラウドネイティブなワークロードは、コンテナ上に構築されたマイクロサービスとして実行され、クラウド上のKubernetesクラスターとしてデプロイされます。コンテナの脆弱性が悪用されると、攻撃者はKubernetesクラスターに侵入する足がかりを得ることができ、そこからクラウド環境内で横方向に移動する方法を見つけることができます。Sysdig 2022 Cloud-Native Security and Usage Reportによると、実運用環境で稼働しているイメージの75%に、パッチ適用可能な深刻度が高いかそれ以上の脆弱性が含まれていることが判明しています。コンテナに存在する脆弱性によって組織が危険にさらされるリスクは、非常に現実的なものです。
コンテナを保護する場合、脆弱性がどこに存在し、どのように環境に侵入するのかを理解することが重要です。コンテナは、コンテナイメージと呼ばれる読み取り専用のファイルからビルドされます。コンテナイメージは、完全にゼロからビルドすることもできますが、より一般的には、他の利用可能なイメージを使用して、階層的な構造を作成することができます。ベースイメージ（Ubuntu、Debian、BusyBox、Alpineなど）は、オペレーティングシステム（OS）の依存関係を提供し、他のすべての層の基礎となるものです。次のレイヤーは、Ruby Gem、Python PiP、Node.js npmなどの言語やフレームワークのイメージになります。それらの容易に入手できるイメージを使用することで、開発者は飛びぬけて開発をスピードアップすることができます。しかし、うっかりするとコンテナに脆弱性を持ち込んでしまう可能性もあります。
多くの開発者は、一般的なレジストリに保存されている公式イメージでさえも安全ではないことに気づいていません。残念ながら、これらのリポジトリは、サプライチェーン攻撃のように、悪意のある行為者によって脆弱なソフトウェアを広める経路として利用されてきました。例えば、DockerHubリポジトリは、公開されているイメージのかなりの部分に、深刻度の高い、あるいは重大な脆弱性が存在することで知られています。一部のリポジトリでは脆弱性スキャンを提供していますが、スキャンはOSイメージに対してのみ行われることが多いようです。
Sysdig 2022 Cloud-Native Security and Usage Reportによると、OS以外のイメージ層に高度の脆弱性や致命的な脆弱性が高い確率で存在する。OSイメージと非OSイメージの両方をスキャンする必要があります。
コンテナ環境ではイメージスキャンは必須です。コンテナ内のアプリケーションコードとすべてのイメージ層の依存関係（OSと非OS）には、ソフトウェア脆弱性が存在する可能性があります。既存のソフトウェアパッケージの新しい脆弱性はいつでも発見できるため、コンテナイメージのスキャンと監査は一度きりで終わるものではありません。このプロセスでは、コード開発から本番環境に至るまで、継続的な監視が必要です。
脆弱性スキャンをDevOpsのライフサイクルに統合する
ソフトウェア開発ライフサイクル（SDLC）に脆弱性スキャンを組み込むことは、Infrastructure as Code（IaC）セキュリティと同様に、継続的インテグレーションおよび継続的デリバリー（CI/CD）プロセスの早い段階でスキャンを組み込むという、シフトレフトアプローチから開始されます。コンテナイメージを早期にチェックすることで、最終ビルドにコストのかかる修正を加えることなく開発を迅速に進め、セキュリティが配信の妨げにならないようにすることができます。CI/CDパイプラインでの脆弱性スキャンの自動化
DevOps プロセスへのセキュリティ導入を成功させるには、開発者の既存ツールとの統合が鍵となります。そこで、CI/CDパイプラインにイメージスキャンを組み込み、開発ライフサイクルの早い段階で（すべてのイメージレイヤー、依存関係、成果物における）脆弱性をキャッチする必要があります。そうすることで、より複雑な後期修正に必要なエンジニアリングサイクルを節約することもできます。GitHub、Google Cloud Build、Amazon Web Services (AWS) CodebuildなどのCI/CDツールとの統合は、スキャン用にイメージを取り出す方法と、インラインスキャンによる方法の主に2つの方法で行うことができます。インラインスキャンは、より安全なプロセスを提供します。インラインスキャンでは、スキャンのために中間リポジトリにコピーを送信する必要がないため、アプリケーションコードが環境を離れることはありません。スキャン結果のメタデータのみが、ポリシー評価のために送信されます。スキャン結果はパイプラインに戻され、パスまたはフェイルのイベントが発生します。
例えば、パッケージの低リスクのバージョン更新を必要とする修正済みの脆弱性のように、自動化または促進できる修正ケースを検討します。また、修正プログラムがない脆弱性や、修正プログラムがあっても複雑な修正が必要な脆弱性については、リスクアセスメントによる補償制御を検討します。
レジストリイメージスキャンの自動化
プライベートなイメージリポジトリやレジストリから脆弱なコンテナイメージを排除することも、セキュリティのベストプラクティスです。組織は、DockerHub、Amazon ECR、Google Container Registry、およびJFrogなどのレジストリサービスを一般的に使用しています。これらのレジストリは、脆弱性スキャン機能を提供していますが、それらが包括的であることを確認してください。レジストリが、各イメージ層、OSおよび非OSの依存関係をカバーしていることも確認してください。ほとんどの場合、OS イメージのスキャンしか提供していないため、スキャンソリューションは、OS 以外のパッケージの脆弱性もチェックする必要があります。開発者は、Python PIP や Ruby Gem など、OS 以外のオープンソースパッケージから無意識のうちに脆弱性を取り込んでいる可能性があり、セキュリティリスクをもたらすことになります。イメージの改ざんに対する保護も重要です。イメージには必ず電子署名を施し、使用前に署名を確認するようにしてください。イメージの署名を確認することで、特定のイメージダイジェストが公開者によって署名されていることを保証することができます。
CI/CDパイプラインの統合の場合と同様に、レジストリとのイメージスキャンの統合は、スキャンを実行するためにイメージをプルすることによって、またはインラインでスキャンすることによって行うことができます。組織は通常、スキャンするためにサードパーティのリポジトリにイメージをプルすることなく行われるインラインスキャンを好みます。
Kubernetesアドミッションコントローラーで脆弱性セキュリティを強化する
Kubernetesアドミッションコントローラーは、Kubernetesクラスター内のコンテナの脆弱性に組織をさらす前の最後の防衛線です。アドミッションコントローラーは、Kubernetesアプリケーション・プログラミング・インターフェース（API）サーバーへのリクエストを評価し、そのリクエストを許可するかどうかを決定します。例として、アドミッションコントローラーがチェックで失敗したステータスを受け取った場合、ポッドデプロイメントのリクエストは拒否される可能性があります。アドミッションコントローラーは、Webhook を使ってセキュリティポリシーを適用するための、拡張可能なソリューションを提供します。そのため、イメージスキャナーをアドミッションコントローラーに統合し、本番でのコンテナデプロイメントの前に脆弱性チェックのステータスを提供することができます。また、Kubernetesのアドミッションコントローラーは、環境仕様に基づいてリクエストを受け入れるか拒否するかの柔軟なルールを提供しています。そのため、脆弱性スキャンソリューションは、クラウド、コンテナ、Kubernetes、アプリケーションの重要性などの環境コンテキストを使用してリスクを評価し、適切なポリシーを定義できるように、スキャン結果内のリッチコンテキストもサポートすることが重要です。
サーバーレスワークロードにおける脆弱性の防止
サーバーレスコンピューティングでは、クラウドプロバイダーが動的にリソースを割り当ててお客様のワークロードを実行しますが、責任共有モデルでは、これらのワークロードを保護するのはお客様の責任になります。コードや依存関係に脆弱性があると、攻撃者はあなたの環境を侵害する手段を得ることができます。サーバーレスワークロードにも脆弱性スキャンを実装することができますし、そうすべきです。例えば、AWS Fargate（基盤となるインフラを管理する必要なく、CaaSとしてコンテナを実行するサーバーレスコンピューティングプラットフォームサービス）上でタスクを起動する前に、AWS ECRリポジトリ内のコンテナイメージのスキャンを自動的にトリガーすることができます。そしてまた、スキャンはインラインで実装することも、イメージをプルすることによって実装することもできます。すべてのレイヤーで脆弱性が検証され、リスクの高いものが見つかった場合はデプロイをブロックできるようにしましょう。
ランタイムの脆弱性管理
ソフトウェアパッケージやOSの新旧バージョンにおいて、日々新たな脆弱性や悪用が発見されています。ビルド段階でのスキャンだけでは、最近発見された脆弱性にさらされたままになってしまいます。ランタイム環境における脆弱性の管理は必要です。脆弱性管理ソリューションは、本番環境に導入されたイメージを追跡し、イメージが新しい脆弱性の影響を受けると、脆弱性データソースからのフィード更新で警告する必要があります。セキュリティツールは、これを実現するためにさまざまな戦略を使用します。1つの方法は、すべてのイメージを定期的に再スキャンすることですが、これはリソースの効率的な使用ではありません。理想的には、デプロイされたコンテナのイメージメタデータが保存され、完全な再スキャンを行わなくても新しい脆弱性を検出できるようにすることです。
この点だけ、追加の観察ポイントを追加しておきましょう。コンテキストを伴わないランタイムの脆弱性アラートは、実際には効果的ではありません。クラウド、Kubernetes、アプリケーションのコンテキストなどの環境情報は、リスク評価、修復の優先順位付け、封じ込めや代償措置に関するガイダンスに必要です。
ホストスキャンの導入
ホストは、コンテナが実行されるコンピューティングインスタンスです。Kubernetes環境では、ホストはPodがデプロイされるクラスターのノードであり、クラウド上の組織の4分の1は、深刻度が高く重大な脆弱性を持つ未パッチのホストを持っていると推定されます。コンテナほど数は多くないものの、パブリッククラウドにおける脆弱なコンピューティングインスタンスは、組織を深刻なリスクにさらすことになります。ホストの仮想マシン（VM）を保護することは、その上で動作するコンテナを保護することと同様に重要です。ホストをスキャンできるツールを導入していることを確認してください。例えば、クラウドVM（EC2などのコンピューティング・インスタンス）は、スキャンが必要なホストです。また、ホストのスキャンは定期的に行う必要があります。そうすることで、チームに実用的な情報を提供し、改善の優先順位付けと迅速な対応を行うことができます。
コンテナとホストに対する単一の脆弱性管理ワークフローの採用
サイロ化したソリューションでは、セキュリティ ギャップと非効率性が生じます。コンテナとホストの脆弱性管理に統一されたアプローチを採用することで、脆弱性の検出と修復にかかる時間を短縮し、アラートの発生を抑制することができます。組織では、環境内で検出された数千もの脆弱性に直面することがよくありますが、チームがタイムリーに対処できるのはそのごく一部にすぎません。優先順位付けと効率的な修復は、脆弱性管理の基本です。リスクはさまざまな形で現れます。コードの脆弱性によって環境が脅威にさらされるだけでなく、セキュリティのベストプラクティスが守られているかどうか、また、組織が遵守しているすべてのコンプライアンス基準や規制を確認することが重要です。
脆弱性の優先順位付けの実施
修正すべき脆弱性にどのように優先順位をつけるかは、リソースに制約のあるセキュリティチームにとって常に課題となっています。脆弱性の重要度を評価すると、現実的なリスクではない脆弱性にサイクルを費やすことになりかねません。優先順位付けを行う場合、重要な判断材料となるのは「待てないもの」です。そのため、重要な脆弱性の環境に対する真の関連性を明らかにする文脈的なリスクも分析に含めるようにしてください。次のような質問を考えてみてください：
- その脆弱性は、コンテナの実行時にロードされ、したがって悪用される可能性のあるパッケージに存在するのか、それとも使用されていないパッケージに存在するのか？
- その脆弱性は、重要なアプリケーションを危険にさらしているか？
- 脆弱性は、外部からアクセスできない環境に存在するか？
- 利用可能なエクスプロイトが存在するか、また存在する場合、どのような脅威活動が報告されているか？
これらの質問に答えることで、あなたの環境のコンテキストにあるどの脆弱性が本当に悪用可能で、組織に高いリスクをもたらすかが明らかになります。これらの領域は、改善のための努力を集中させる必要がある領域です。
脆弱性を管理するには、環境におけるリスクを効果的に低減する方法を理解する必要があります。脆弱性スキャンソリューションが、コンテナやホスト上の脆弱性を検出できることを確認してください。優先順位付けと修復のために脆弱性アラートとともに提供される脅威データとコンテキストの品質をチェックし、エクスポージャリスクを低減するための改善を追跡してください。
コンプライアンス要件の確認
ホストとコンテナの統合スキャンは、脆弱性のチェック以外にも活用できます。スキャンは、規制コンプライアンス（たとえば、PCI DSS、NIST規制、SOC 2）や、CIS（Center for Internet Security）ベンチマークなどのセキュリティベストプラクティスを検証することも可能です。スキャナーは、セキュリティ管理の中でも、ポートの誤設定、保護されていない機密、オープンソースソフトウェア（OSS）ライセンス、ファイルの完全性などのセキュリティリスクを検出する必要があります。クラウドセキュリティについてもっと知りたいですか？
Infrastructure as Code（IaC）、脅威への対応、コンテナやクラウドのコンプライアンス維持などのトピックをご覧ください。