
パロアルトネットワークスは木曜日、クラウド、DevOps、セキュリティに焦点を当てた年次「Code to Cloud サイバーセキュリティサミット」を開催しました。専門家たちが、コーディングとクラウドのトレンド、機会、課題について議論しました。
Palo Alto NetworksのUnit 42は先日、クラウド脅威レポートを発表し、セキュリティチームがセキュリティアラートを解決するのに平均6日かかることを明らかにしました。同社のクラウドネイティブセキュリティの現状調査では、組織の90%が1時間以内にサイバー脅威を検知、封じ込め、解決できていないことが明らかになりました。Unit 42はまた、API脅威に関する新たな調査も最近発表し、2022年後半の攻撃の14.9%がクラウドホスト型のデプロイメントを標的としていることを明らかにしました。
このイベントの講演者の一人は、Palo Alto Networks Prisma Cloud の最高技術責任者である Ory Segal 氏で、開発者が従う過酷な開発サイクルにクラウド セキュリティをどのように適合させることができるかについてのパネルに参加しました。
イベントに先立ち、彼はTechRepublicに対し、ソフトウェア開発プロセスとクラウドネイティブアプリケーションプラットフォーム(CNAPP)の擁護について語った。(図A)
図A

ジャンプ先:
- プラットフォームとしてのCNAPP
- ソフトウェア開発パイプラインのセキュリティ確保
- パブリッククラウドがCI/CDに脆弱性を生み出す仕組み
- サプライチェーンの保護
- Prisma Cloud で CI/CD セキュリティを強化
- ヒドラ問題を回避するために左にシフトする
プラットフォームとしてのCNAPP
TR:現在、CNAPP(クラウドネイティブ・アプリケーション保護プラットフォーム)とは何でしょうか?その範疇に含まれるものは何でしょうか?また、DevOpsセキュリティ、クラウドに移行されたアプリケーションやクラウド環境向けに開発されたアプリケーションの脆弱性軽減といった点において、CNAPPへの様々なアプローチをどのように捉えているのでしょうか?
シーガル: CNAPPとみなされるレベルに到達する企業は、その経緯によって異なります。例えば、Twistlock(Palo Alto Networksが買収)やAqua Securityのように、コンテナセキュリティからスタートした企業もあれば、クラウドセキュリティ体制管理から参入した企業もあります。つまり、誰に聞くかによって答えは大きく異なります。しかし、私はガートナーの見解に共感します。ガートナーは包括的なクラウドネイティブセキュリティに重点を置いており、「クラウドセキュリティ」「ワークロードセキュリティ」「コードセキュリティ」といった言葉で括るのではなく、コーディング開始からデプロイ、ワークロード監視に至るまで、開発ライフサイクル全体を通して適切なセキュリティ制御を適用できるプラットフォームを提供するという点を重視しています。そして、その下には実に様々な製品カテゴリーがあり、その全てがCNAPPの一部であると直接考えられるわけではありません。
TR:開発カスケードやサイクルにおけるCNAPPの良い例にはどのようなものがありますか?CNAPPはDevSecOps全般を指す包括的な用語ですか?
シーガル:つまり、ソフトウェア開発においては、インフラストラクチャ・アズ・コード(IaaS)テンプレートをスキャンし、左側に何らかのリスクや構成ミスが埋め込まれていないことを確認すること、そしてソフトウェア構成分析を実施して(不正コードや脆弱性による)リスクの展開を回避・防止することが重要です。現在検討中でまだ提供していない静的分析も重要ですが、SAST(静的アプリケーション・セキュリティ・テスト)、DAST(動的アプリケーション・セキュリティ・テスト)、IAST(対話型アプリケーション・セキュリティ・テスト)といった、いずれも一般的なアプリケーション・セキュリティ・テストであり、その一部であると考えています。
参照: 従来のプレイブックに固執するのはクラウド セキュリティの間違い(TechRepublic)
TR:さらに右に行くと生産に近づいていくのでしょうか?
シーガル:製品の構築、アーティファクトのスキャンとセキュリティ保護、クラウドへのデプロイプロセス、実行中のワークロードの監視と保護などを行います。これには、ランタイム保護、WAF(Webアプリケーションファイアウォール)、アプリケーションプログラミングインターフェース(API)セキュリティ、そしてセキュリティオペレーションセンターやワークロード監視といった、より具体的な関連事項が含まれます。
ソフトウェア開発パイプラインのセキュリティ確保
TR: CNAPP に該当するこれらすべてのアプリケーションの中で、利用可能なソリューションのほとんどで十分に対処されていない領域はありますか?
Segal:そうです。それに加え、Cider Security の買収によって現在私たちが検討しているのは、ほとんどの人が無視しているかまだ考えていないことですが、CI/CD (継続的インテグレーション/継続的開発) パイプライン自体のセキュリティです。これは現代の開発環境では、それ自体が非常に高度で複雑なアプリケーションを構成しています。
TR:でも、CI/CDパイプラインは、いわばネックレスのビーズのようなものですよね?具体的には、CI/CDパイプラインと、コードからクラウドへの段階的なDevOpsプロセスの違いは何でしょうか?
シーガル:顧客向けに構築しているアプリケーションではなく、自社のソフトウェアを構築するために使用しているアプリケーション、例えばサードパーティ製のライブラリを導入している場合や、JenkinsやCircleCIを使ってコードをビルドし、成果物を生成する場合など、それらの点もセキュリティ保護されているでしょうか?たとえ最も安全なクラウドネイティブアプリケーションを作成してデプロイできたとしても、誰かが何らかの方法でパイプライン自体、つまりビルドとデプロイのプロセスを改ざんできた場合、せっかくコードに組み込んだセキュリティ対策も無駄になってしまいます。
TR:誰かがパイプラインに毒を盛る可能性があるからです。
シーガル: 2020年にSolarWindsで発生したように、マルウェアを埋め込むことも可能です。また、最近も何度も発生しています。そのため、この件についてもCNAPPの一部として検討しています。ただし、そのように説明されることはあまりありません。
パブリッククラウドがCI/CDに脆弱性を生み出す仕組み
TR:クラウドベースのオープンソース コードベースとハイブリッド作業は、CI/CD にどのような影響を与えていますか?
シーガル:かつてのソフトウェア開発方法(言語やフレームワークのことではなく、ビルドプロセスそのものについてです)では、ソースコード管理をローカルサーバー上で実行していました。データセンターではなく、自社のITインフラ上で実行していました。コードをローカルでプル/プッシュし、ビルドしてCDに焼き、顧客に出荷していました。現在、私たちが関わっている組織のほとんどは、何らかのGitリポジトリ(完全にパブリックインターネット上)を使用しており、ビルドにはJenkins、GitLab、CircleCIなど、ますます多くのサービスが利用されています。これらのほとんどは、Build-as-a-Service(BaaS)プラットフォームとして利用されています。
TR:つまり、いかなる意味でもローカルではなく、境界内で保護されていないということですか?
シーガル:本質的には、ワークフロー全体がある程度パブリックインターネット上でホストされています。さらに、開発者は開発に自分のラップトップを使用することが多く、ブラウザ経由でGitリポジトリにアクセスすることがよくあります。フィッシングメールやその他のソーシャルエンジニアリング攻撃を受信して応答した場合、攻撃者に操作され、例えばブラウザからセッショントークンを盗まれる可能性があります。これにより、攻撃者はGitHubリポジトリに直接アクセスできるようになります。そこから、開発プロセスを汚染し始めることができます。つまり、ゼロトラストの観点から見ると、今日のソフトウェア開発方法において最も機密性の高いポイントが露出しており、十分に管理されていないと言えます。つまり、もはや境界は存在しないのです。
サプライチェーンの保護
TR:サプライ チェーンの保護という点では、CI/CD パイプラインの健全性を確保するように設計された他の製品に戻りますが、in-toto のようなオープン ソースの製品があることは知っています。これらの製品は、開発プロセスのすべてのステップで署名を保証するため、目に見えない脆弱なポイントが残ることはありません。
シーガル:そのプロジェクトについては検討しました。数か月前にイスラエルのスタートアップ企業、Ciderを買収しました。同社はこの分野のパイオニア的存在でした。この買収の一環として、CI/CDパイプラインにセキュリティガードレールを適用する新しいセキュリティモジュールを開発しています。
TR:これはセキュリティ チームにとってどのようなメリットがありますか?
シーガル:セキュリティ担当者にとって、これは開発パイプラインを明るく照らす「明かり」を灯すようなものです。なぜなら、ウォーターフォールモデルからシッピングモデルに移行した現在、ITセキュリティアプリケーションチームはCI/CDプロセスに関して完全に疎外されており、多くのお客様が1日に複数回、あるいは週に複数回コードをプッシュしているからです。毎週、より多くの新しいものを開発・プッシュしなければならないという競争上のストレスがチームに大きくのしかかり、開発者は機能のコーディングで非常に忙しくなっています。彼らに静的コード分析の使用を求めることさえ、少し無理があります。このパラダイムにおいて、ITセキュリティチームやアプリケーションセキュリティチームはボトルネックになってはなりません。彼らは妨害者であってはなりません。むしろ、支援者として認識されるべきです。
TR : では、それは実際には何を意味するのでしょうか?
シーガル:つまり、プッシュされるすべてのコードをスキャンするためのプロセスを停止することはできないということです。CI/CDパイプラインの性質、開発者がコードをプッシュしている場所、アーティファクトや依存関係、そしてリスクの有無(例えばBuild-as-a-Serviceプラグインがコードにアクセスできるかどうかなど)について、全く可視化されていません。
TR:「アーティファクト」とはバイナリのことですか?
Segal:バイナリ、コンテナイメージ、サーバーレス関数コード、さらにはEC2(Amazonのクラウドコンピューティングプラットフォーム)イメージなども含まれます。これには、クラウドにプッシュできる状態のイメージや関数としてパッケージ化された、すべてのサードパーティ製パッケージが含まれます。
Palo Alto Networks Prisma Cloud が CI/CD セキュリティを強化
TR: CI/CD のセキュリティ保護に特化した Palo Alto Prisma Cloud 製品をリリースされるんですね。
シーガル:はい、ソフトウェアサプライチェーンのセキュリティ確保のため、Prisma CloudプラットフォームにCI/CDセキュリティモジュールを追加する予定です。まず、クラウドアカウント、コードリポジトリ、ビルドプロセスをオンボーディングします。その後、すべてのスキャンを開始します。左側でコードをスキャンします。コンテナイメージなどの関連アーティファクトはビルド時にスキャンし、右側でランタイム保護を適用します。そして、これらはすべてクラウドセキュリティチームによって管理・運用されます。このチームは、クラウドにプッシュするまでのエンドツーエンドのプロセスを担当しています。クラウドアカウントのセキュリティを確保し、リスクのある資産がクラウドにデプロイされないようにします。
参照:クラウドセキュリティに「木を見て森を見ず」問題が発生する理由(TechRepublic)
TR:明らかに、シフトレフトが最も重要です。なぜなら、欠陥のある、または脆弱なコードベースをクラウドにデプロイすると、ヒドラを作成してしまうからです。
シーガル:例えば、あなたが書いたファイルの1行のコードがリポジトリに取り込まれ、複数のクラウドアカウント上の多数の異なるクラスターにデプロイされる複数のコンテナイメージが生成されます。つまり、モグラ叩きのように右側の問題に取り組もうとすると、同じ問題のインスタンスを何千個も修正してパッチを適用しなければなりません。
パロアルトネットワークスが「ヒドラ問題」を回避する方法
TR:それがすでに世に出回るまで待っていたら、1つの問題ではなく、何千もの問題に対処することになります。
問題が広範囲に広がります。どうすれば解決できるでしょうか?
シーガル:こう考えてみてください。アプリケーションのショッピングカート機能のコードにミスがあったとします。そのアプリケーションは現在、複数のリージョンにある複数のクラウド(Google Cloud、AWS、Azureなど)のトラフィックをサポートするために冗長的に稼働している5,000個のコンテナにデプロイされています。すると、ランタイム側から、脆弱なインスタンスが5,000個あるというスキャンアラートが届きます。プラットフォームが十分にインテリジェントであれば、問題のコード行と、特定の開発者がコミットした特定のコードまで遡ってマッピングできます。その開発者にチケットを発行して問題を修正すれば、数千のインスタンスで問題を解決できます。また、これらの問題には優先順位を付ける必要があるでしょう。例えば、コードレベルで結果を確認し、修正が必要な問題が1,000個あるとします。どの問題が最も深刻か、どうすればわかるでしょうか?本番環境からの情報があれば、本番環境のミッションクリティカルな環境で使用されている脆弱なコードを特定できます。一方、ステージング環境のみで発生している問題はそれほど深刻ではなく、差し迫った脅威ではないため、特定は容易ではありません。これらは、CNAPP によって可能になるはずです。
TR:そうですね、それは潜在的に多くの時間を節約できるので重要ですね?
シーガル:その通りです。潜在的な依存関係は数百万もあるため、実際には関連性のある依存関係にのみ焦点を当てれば良いのです。静的な側面だけでなく、ランタイムの可視性を持つことが大きな違いを生みます。例えばPrisma Cloudでは、Cloud Workload Protectionが実行中のコンテナで実際にメモリにロードされているソフトウェアパッケージを記録します。これは非常に貴重な情報です。このデータは、何を優先的に修正すべきかを判断するためにまさに必要な情報です。