サプライチェーンセキュリティのベストプラクティス概要 #aqua #コンテナ #セキュリティ #サプライチェーン攻撃 #動的解析
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2021年9月30日に公開された「 A Brief Guide to Supply Chain Security Best Practices 」の日本語翻訳です。
サプライチェーンセキュリティのベストプラクティス概要
クラウドネイティブアプリケーションのサプライチェーンを標的とした攻撃が増加している中、サードパーティのパッケージやツールを介して環境に侵入してくるリスクにどのように備え、阻止するかを理解することが重要です。この記事では、あらゆる組織のクラウドネイティブ戦略に含めるべき、ソフトウェアサプライチェーンセキュリティのベストプラクティスを紹介します。
DevOpsチームに権限を与え、DevSecOps文化を育む
この提言は、チームが DevOps を象徴する様々な無限ループ図で表現されるような方法を使用して作業を始めていることに由来します。DevOps のループという芸術的なビジョンから価値を得るための鍵は、クローズドループワークフローの一環として、明確で正確、かつ実用的なセキュリティの洞察を開発者に伝えることです。これを「セキュリティのシフトレフト」と表現されることを聞いたことがあるでしょう。
利用するパッケージやライブラリ、あるいはリスクを軽減するための手順について賢明な判断を下すためには、開発者がリスクを認識し、その回避方法や対処方法について教育を受ける必要があります。これには、効率性を妨げる要因を特定し、確立されたワークフローにセキュリティを組み込み、セキュリティリスクの情報を必要とする人の手やツールに直接届けるという考え方も含まれます。
しかし、私たちがすでに知っているように、最も手間がかからない手法が好まれます。セキュリティは生産性を妨げるものではありません。もし、セキュリティが生産性を妨げてしまうのであれば、各開発者が本番稼動中のプロジェクトのセキュリティを他の人に任せることがあまりにも容易になってしまいます。そうなると、「コモンズの悲劇」に陥り、近視眼的な自己利益がチームの負担になってしまうのです。
推奨事項
フィードバックループを確立し、明確なセキュリティリスク情報と改善策のガイダンスを開発チームやエンジニアリングチームに提供します。確立された DevOps ワークフローに準拠した方法で行うことで、標準的な運用にセキュリティを組み込む可能性が高まります。
CIパイプラインにおけるセキュリティ管理の自動化と組み込み
セキュリティの自動化は、他の対策の結果として捉えられていることがあります。実際には、セキュリティを(部分的にでも)自動化できるように組み込むことは意図的なプロセスであり、開発チーム、セキュリティ、あるいは DevOps が使用しているツールの設定を変更するだけでは起こりません。
多くのセキュリティ専門家が自動化に対して懸念を示していることを認識することは重要です。一般的には、コントロールを犠牲にしたり、ワークフローを妨げたり、セキュリティ問題がパイプラインを通過することを可能にするような条件を過剰に設計したりすることへの懸念があります。しかし、セキュリティと自動化という2つの考え方は、自動化されたシステムにおいてセキュリティチームのプロキシとして機能する適切なツールとセキュリティチェックにおける明確な基準があれば、協調して機能できます。
推奨事項
安全な自動化を促進するために、適切なポリシーとコントロールを確立する。これらのポリシーを有効にするため、過度に特殊な条件や一般的な条件を作らないよう注意しましょう。スケーラビリティ(拡張性)を考慮してポリシーを作成し、条件が満たされなかった場合に発生するステップを明確に定義してください。これは、コントロールを拡張し、より速いデプロイサイクルに合わせてコンプライアンスを維持するために重要です。
サプライチェーンにおけるリスク許容度とセキュリティ基準の設定
ポリシーとコントロールを策定する際には、セキュリティリスクを評価する人、 ポリシー違反を判断する人、セキュリティリスクを修正する人、 運用環境のセキュリティの責任者など、関連するすべてのステークホルダーを巻き込むことが重要です。これらの関係者が協力して、パイプラインを流れるソフトウェアアーティファクトのセキュリティリスク耐性を定義し、セキュリティリスクが本番環境で問題となる前に検出、優先順位付け、修正を行う必要があります。
しかし、ソフトウェアのサプライチェーンを経由して入ってくるアーティファクト、パッケージ、ライブラリの集合体を考えると、この作業はかなり複雑になります。
これは、ほとんどの組織が、より高いアジリティ、スケーラビリティ、または効率性と引き換えに、サプライチェーンにある程度のコントロールを委ねているためです。サードパーティから取り込んだリソースに対して、従来のアプリケーションセキュリティテストの方法では、リスクを特定できない可能性があり、修復は社内の開発チームが常に達成できるタスクではない可能性もあります。したがって、サプライチェーンパッケージに対するリスク許容度とセキュリティ基準は、例えばカスタムコードに対するものとはおそらく異なるでしょう。
推奨事項
開発者とセキュリティ関係者との会話を促進する。「コード内のリスクとサプライチェーンを経由して侵入してくるリスクのレビュープロセスはどのようになっているか」、「どのような対応と修復のステップが自動的に行われ、誰が通知されるか」などのプロンプトを提供しましょう。
ソフトウェアのサプライチェーンが関わっている場合、この2つの答えは自分のチームや組織以外の人が関わっている可能性があるため、リスクの許容度とそれに伴う活動に反映させる必要があります。このようなシナリオでは、問題の解決は、問題をベンダーに通知する長いプロセスの結果としてのみ行われ、ベンダーの対応に関する SLA へ従う可能性があります。
セキュリティ戦略から「信頼」を排除する
サプライチェーン攻撃に関する以前のブログでは、信頼が攻撃のベクトルや悪用の入口として利用されている例をいくつか紹介しましたが、今回はその例を紹介します。開発者に脆弱性情報を提供したり、SDLC や CI/CD パイプライン全体でセキュリティテストを統合できます。しかしソフトウェアのサプライチェーンでは、これらのセキュリティ手順が実行されなかったり 、効果がなかったりするなど、多くの潜在的なリスクポイントが発生します。
推奨事項
信頼できるベンダーであっても、自社内のセキュリティチーム、DevOps チーム、開発チームと同じ厳格さと基準でソフトウェアセキュリティに取り組んでいない可能性があることを、組織全体で理解してもらう。クラウドネイティブセキュリティツールキットと DevSecOps プロセスには、これを反映させる必要があります。このことが社内のすべての関係者に理解されて初めて、これまでの3つの段階が効果的で一貫性のあるものになる可能性が高くなります。
ソフトウェアサプライチェーンセキュリティプランの策定方法
これらの4つのステージを統合することで、クラウドネイティブアプリケーションにおけるソフトウェアサプライチェーンのリスクに対処するための健全なアプローチが可能になります。つまり、前述したような巧妙な攻撃にも対応できるようにセキュリティアプローチを拡張し、攻撃が実行される前に攻撃のキルチェーンを追跡して可視化することが必要です。
一般的に、成功の可能性を最大限に高めるためには、ソフトウェアを実行する必要があります。もちろん、このソフトウェアを初めて実行するのが本番環境であってはなりません。安全なサンドボックス環境でコンテナを実行し、実行時にのみ現れる悪意のある動作を特定して追跡するためのセキュリティソリューションを準備しておくことが大切です。
検出された悪意のある動作や異常な動作は、本番環境に悪意のあるアーティファクトがデプロイされないように予防措置を講じ、通知と対応のカスケードを開始する必要があります。可能な限り、ビルドプロセスや CI/CD パイプラインの一部として自動化することが重要です。そうすれば、セキュリティチームや DevOps チームに負担をかけたり、リスクが検出されなかった場合等の不必要な理由でデプロイ期限に間に合わなくなったりすることなく、すべてが本番前にテストされます。
この設定により、組織は標準的なワークフローを実行し、分析中に発見された悪意やリスクのある異常な動作やアーティファクトについて、最終的に詳細なレポートを得ることができます。この分析結果は、適切な行動をとるために洞察を必要とする人に共有されます。ベストプラクティスに則り、このために導入するセキュリティソリューションがどのようなものであれ、ポリシーをサポートできることを確認してください。これにより、自動化の要件を容易にし、かつセキュリティリスクの露出をコントロールできます。
サプライチェーンのセキュリティリスクに対するポリシーに盛り込まれる基準やリスク許容度は、従来のソフトウェアの脆弱性(開発者が選択したオープンソースコンポーネントの CVE や、カスタムコードの CWE など)とは異なる可能性があることを覚えておいてください。これは、ソフトウェアのサプライチェーンを通じて取り込まれたリスクに対する修復のコントロールができないためです。
さらに、アプリケーションが本番前のサンドボックス環境で実行されているときに発生するすべての行動やアクションを検証することも重要です。もちろん、安全な本番用ではないサンドボックス環境の中で明らかにされているので、本番用の機密資産を危険にさらすことなく、それらを観察し、レポート化できます。コンテナ内で使用されるものには何らかの動作があり、その動作は悪意のある動作の可能性があります。これは今日のソフトウェアサプライチェーンに内在するリスクです。
最後に、検出された動作を MITRE ATT@CK フレームワークのような基準で自動的に分類することで、SecOps とフォレンジックをサポートします。これにより、収集した洞察を組織のソフトウェアセキュリティのリスク状態という大きなストーリーに同化させることができ、セキュリティチームがクラウドネイティブアプリケーション、レガシーアプリケーション、内部ソフトウェア、商用技術のリスクプロファイルを総合的に見たときに、無駄な比較を防ぐことができます。
これらのベストプラクティスを実現する Aqua の Dynamic Threat Analysis のような自動化されたメカニズムをクラウドネイティブセキュリティ戦略に組み込むことで、セキュリティチームや DevOps チームに新たな負担をかけることなく、サプライチェーンリスクの露出を大幅に削減できます。
- 運用中のソフトウェアのセキュリティを証明しなければならない運用チームに負担がかかるようなことはありません。
- リスクを十分に評価したいというセキュリティチームのニーズを満たします。
- サードパーティやベンダーが提供するパッケージを調達する際の開発者の不安を解消します。
- フォレンジック要件やコンプライアンス基準をサポートするための効果的な方法を確立します。
サプライチェーンセキュリティに関する詳細については、「Supply Chain Security in the Cloud Native Stack」のウェビナーで全容を確認できます。
