クラウドネイティブセキュリティベストプラクティス：脆弱性管理 #AquaSecurity #セキュリティ #脆弱性管理 #ベストプラクティス
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2019年12月12日に公開された「 Cloud Native Security Best Practices: Vulnerability Management 」の日本語翻訳です。
クラウドネイティブセキュリティベストプラクティス：脆弱性管理
私たち Aqua Securityが、クラウドネイティブアプリケーションのセキュリティツールを提供し始めてから4年経ちました。その間に、私たちは実運用におけるベストプラクティスを学んできました。多くの組織はセキュリティ目標を達成するための健全なプロセスとツールの確立に成功しています。しかし、対応の優先順位付けと管理に苦労している人々もいます。
このシリーズのブログでは、クラウドネイティブワークロード環境におけるセキュリティベストプラクティスについて、Aqua CSP が対処する4つのコアセキュリティの懸念に焦点を当てて確認していきます。今回は第一弾として脆弱性管理のベストプラクティスについて説明します。
コンテナおよびサーバーレス環境における脆弱性管理
脆弱性を可視化することは、攻撃対象領域を減らしてリスクを排除するための鍵です。これは多くの組織が取り組むべきタスクです。コンテナ化された環境ではセキュリティリスクを開発段階で洗い出すことが可能となり、セキュアなアプリケーションが本番環境にデプロイされるための最初のステップとして適しています。
CI/CD ツールを使用して開発されたコンテナイメージ・function には、効果的な脆弱性管理を行う上で対処が必要な、いくつかの課題があります。
- 脆弱なイメージと function の発見 :
脆弱性を早期に発見し、対応していくことが肝要となります。これは CI パイプラインでのスキャンに限らず、レジストリまたは function ストアに対してスキャンすることも重要です。また、レジストリにプッシュされていない、ホスト( VM )上に直接保存されているコンテナイメージも見落としてはいけません。 - 全体的なリスクによる脆弱性の優先順位付け :
例えば重大度の高い脆弱性であっても、それに関連するコンポーネントが使用されていない場合は、本番環境で稼働する100のコンテナが使用されているコンポーネントが持つ中程度の脆弱性よりも、リスクが低い可能性があります。 - 誤検知の排除 :
残念ながら NVD ( National Vulnerability Database ) のような公共機関のデータベースのみに依存することはあまり好ましくありません。NVD はよく4～5週間遅れて更新することがあり、かつ誤検知も多く含まれています。CVE は実際よりも深刻度が高く評価されていたり、あるいは既に修正済みのこともあります。適切なコンテキストは誤検知を排除するのに役立つため、複数の情報源や研究結果に基づいた調整が必要です。 - 脆弱なコンポーネントとその所有者の理解 :
コンテナイメージの構造は平坦ではなく、たいてい依存関係があります。ベースイメージと複数の脆弱性に対する根本原因を特定することは重要です。根本原因を修正することは、他のイメージで異なる脆弱性として検知されることを回避するための鍵となります。 - 修復情報の取得 :
イメージに脆弱性が見つかりました。どのように修正しますか? fix リリースはありますか?開発者は何をすべきですか? - 例外を処理し、fix がリリースされていない脆弱性から保護する :
理想の世界では脆弱性は全て排除しなければいけません。しかし現実的には多くの組織で、他に替えが無いという理由だけで脆弱なアプリケーションを実行していることがあります。問題はこれらの例外をどのように処理し、妥当な期間内に fix がリリースされていない脆弱性を軽減するかです。 - プロセス全体の自動化とスケーリング :
多くの組織が1日に数万ものイメージをスキャンしている現在、少数のイメージのみ処理できるツールが膨大な数のイメージを処理できる保証は全くありません。
脆弱性のイメージをスキャンするいくつかのツール(オープンソースツールを含む)が、市場に存在します。しかし、それらのカバレッジ・精度・そしてもちろんスキャン結果に対処する能力は大きく異なります。かつて顧客が私に言いました。「私たちが利用しているイメージに非常に多くの脆弱性が含まれていることを知れたことは素晴らしいことです。しかし、これから何を対処していけばいいのでしょうか。」
いくつかのベストプラクティスと、Aqua CSP のようなエンタープライズ級のプラットフォームで可能な対処方法を見ていきましょう。
レジストリとfunctionに対するスキャン
SDLC (システム開発ライフサイクル)においては、できるだけ早い段階でスキャンを開始することをお勧めします。Aqua は事実上すべての CI/CD ツールと統合が可能であり、イメージや function をビルド時にスキャンできます。これにより問題を早期に検出し、迅速な修復を可能にします。
CI/CD 時のスキャン後もレジストリに対して継続的にスキャンする必要があります。ビルド時に問題がなかったイメージ・function に、後日新たに脆弱性が発見されたり、CI プロセスをバイパスしたイメージがレジストリにプッシュされる可能性もあります。多くの組織は複数の CI ツールと複数のレジストリ(異なるチームやステージ用)を使用しており、これらすべてをスキャンする必要があります。Aqua CSP は、Amazon ECR・Azure ACR・Google GCR・Harbor・JFrog Artifactory・Sonatype Nexus・Red Hat Quay・Docker Trusted Registry等のレジストリと容易に接続できます。
アプリケーションリスクに焦点を当てる
次に直面する課題は大規模なセキュリティを提供することです。ここで言う大規模とはスキャンされる可能性のある数十万のイメージを指します。イメージの数が非常に多いため、膨大な数の脆弱性に対して、修正の優先順位付けをする必要が生じます。レジストリは開発環境・ステージング環境・本番環境で使用するイメージを格納しています。しかし、これらのイメージの多くは本番環境で使わないものであり、それらが脆弱であったとしても実質リスクとはなりません。Aqua CSP は実行中のワークロードに内包する脆弱なコンポーネントを可視化します。これによりセキュリティチームは、最も悪用される危険性にさらされているコンポーネントの修正に集中できます。
ベンダーのスコアで誤検知を削減
脆弱性に関する Aqua CSP スコアリングシステムはNVD（National Vulnerabilities Database ）によって報告されたCVSS脆弱性スコアに基づいていますが、パッケージベンダーのスコアも取り入れています。CVE の重大度のレポートがNVDとベンダー間で矛盾がある場合は、誤検知を最小限に抑えるためにベンダースコアが優先されます。多くの場合、ベンダーは脆弱なコードを修正する以外の方法でCVEのリスクを減らすため、ベンダースコアは低くなります。稀に下図のように、ベンダーがNVDの評価よりもCVSSを深刻に評価することもあります。
アプリケーション所有者を特定する
所有権の可視性は効果的・効率的な脆弱性修正プランにとって重要です。アプリケーションの所有者を特定しやすくするために、Aqua CSP は多くの場合電子メールアドレスとともにDockerfileのAuthor変数で指定した作成者を表示します。
ベースイメージへの対処
多くのイメージは他のイメージをベースにしているために脆弱性を継承してしまいます。そういった場合、脆弱性は複数のイメージに現れるため、これらの脆弱性の原因を理解することが重要です。ベースイメージを修正することでそれらの脆弱性が使用されるすべてのイメージが修正されます。Aqua CSP はベースイメージに内包されている脆弱性を表示し、ソースを分離することでより効率的な修復を可能にします。
レイヤーごとの脆弱性の表示
脆弱性が検知された場合、どのレイヤーで検知されたものなのか分からないツールが多いです。Aqua CSP は対処する脆弱性に関連付けられているレイヤーを特定することができます。さらに脆弱なパッケージに利用可能な修正がある場合、Aqua CSP は提案された解決策としてそれを表示します。
実用的なアドバイス
開発者は、コードの脆弱性について通知されると対処方法について悩みます。Aqua CSP では脆弱性情報の一部として、問題を修正するために何をすべきか具体的なアドバイスを提供します。通常特定の新しいバージョンへのアップグレード、場合によっては構成変数または環境変数の変更が推奨されます。
脆弱性の検知とその後:修正するか、許容するか
理想の世界ではすべての脆弱性を修正する必要があります。不変性が基本となるクラウドネイティブ環境では、ソースイメージ・function の再ビルドで脆弱性が修正されたバージョンへ更新して修正を行います。しかし、残念ながらそれが常に可能であるとは限りません。たとえば単純に修正が利用できない場合や、依存関係が多数あり修正に長い時間がかかる場合です。
その間に何をしますか? Aqua にはこのための2つのオプションがあります。まず Aqua Vulnerability Shield を使用して、脆弱性の悪用を防ぐためのランタイムポリシーを適用できます。これが不可能、または適用できない場合は Aqua によって有効期限を設定することにより、脆弱性のリスクを一時的に受け入れるオプションがあります。これにより開発者は修復オプションを探すのに必要な猶予期間が与えられます。
集中型脆弱性管理システムとAquaを統合
Aqua CSP を使用して脆弱性リスクを表示する包括的なレポートを生成できます。これらのレポートは次のような質問に対応します。
- 何を修復する必要があるか
- 利用可能な fix バージョンはあるか
- アプリケーションの所有者は誰か
ほとんどの企業は一元化されたセキュリティ管理・評価・および優先順位付けのために一つのビューで完結できるものを望みます。これを実現するため、API 統合や CSV レポートを使用して、Aqua CSP のレポートをサードパーティシステムにエクスポートすることが可能です。
次回
クラウドネイティブセキュリティのベストプラクティスシリーズの次回の投稿をお楽しみに。クラウドネイティブ環境の最大の課題の1つを取り上げ、実行中のワークロードの可視性とセキュリティの評価方法を説明します。また CI/CD パイプラインを保護する方法、生産性に影響を与えずにパイプラインのセキュリティゲートを設定する方法についても説明します。
