クラウド サプライ チェーンの 保護
サプライ チェーンのセキュリティは多くのリーダーにとって最大の関心事になって います。インシデントに次ぐインシデントによってサプライ チェーンの脆弱性が明 らかになり、組織の重大なリスクが露見しているからです。Log4j や SolarStorm な どのセキュリティ課題はあらゆる規模の組織に打撃を与えますが、組織はそのリスク の存在に気付いてもいないことがあります。サプライ チェーンが攻撃を受けると、ソ フトウェア スタックの 1 つのコンポーネントにある脆弱性によって、組織全体が潜 在的なエクスプロイトにさらされる可能性があります。
パロアルトネットワークスの Unit 42 の調査 では、主要な懸念材料となる、クラウド サプライ チェーン内で特に影響の大きいリスクのタイプを特定しました。調査チー ムは、クラウド インフラストラクチャの構築に使用されているサードパーティの コードの 63% が安全でないことを発見しました。このセキュリティ リスクには、組 織をリスクにさらすような設定ミス、権限の不適切な割り当て、脆弱なコード ライブ ラリなどが含まれます。
クラウド サプライ チェーンとは
人々がサプライ チェーンについて語るとき、ほとんどは、1 つの場所から別の場所へと移動する物理的なウィジェットや商品のよ うなものを思い浮かべます。多くの組織が未だに理解していないのは、こうした物理的商品の移動の多くが、クラウド内で実行され ているアプリケーションによって可能になっているという事実です。さらに踏み込んで、組織が独自のクラウド ネイティブ アプリ ケーションを構築すると、サプライ チェーン内部にサプライ チェーンが生じることになります。
最新のクラウド ネイティブ アプリケーションは、大まかに 3 レベルのステップで構築および構成されます。最初のレベルは、クラ ウド インフラストラクチャのプロビジョニングです。2 番目のステップは、Kubernetes® コンテナ オーケストレーション サービス の配置です。このプラットフォーム上にアプリケーションを導入します。3 番目のステップは、アプリケーション コンテナ イメー ジそのものの導入です。この 3 つのレイヤーのすべてに、設定ミスや脆弱なコード要素が存在する可能性があります。
SBOM ( ソフトウェア部品表 ) の簡素化
クラウド サプライ チェーンのセキュリティは複雑になりがちですが、単純化する機会も提供されています。クラウド ネイティブ ア プリケーションでは、ほとんどの場合コンテナが使用され、これによって組織はアプリケーション内に実際に存在するものを簡単な 方法で追跡できます。
ソフトウェア部品表 (SBOM) の概念はコンテナによって簡素化されます。コンテナは宣言的だからです。ユーザーはコンテナ マニ フェスト内を 1 行ずつ確認し、コンテナ内に何があるのか把握できます。
SBOM はソフトウェア サプライ チェーンにますます組み込まれるようになっています。これは、米国政府のサプライヤに SBOM の 使用を義務付けした 大統領令 14028 のおかげでもあります。
クラウド サプライ チェーンの保護に向けた推奨事項
すべての異なるレイヤー、コンポーネント、ソースを考えると、クラウド サプライ チェーンは複雑だと言えます。複雑ではあるも のの、クラウド サプライ チェーンのセキュリティは、次の 4 ステップの戦略的アプローチによって管理することができます。
ステップ 1: 戦略を定義する
最初の重要なステップは、クラウド サプライ チェーンに対する全体戦略を概観することで、シフトレフト アプローチの採用から開 始します。シフトレフトの考え方の要点は、プロセスの早期にセキュリティを導入することで、DevSecOps と呼ばれることもあり ます。この戦略は大量のドキュメントにまとめる必要もありません。最初に本当に必要なものは、ビジョン、ロール、責任の概要で す。ここから時間をかけて反復します。
ステップ 2: ソフトウェアがどこでどのように作られているかを把握する
ここでは、組織においてソフトウェアがどこでどのように作られているかを把握するために、少し詳しく調査する必要があります。実際に現場に出向き、ソフトウェアが開発者のラップトップから本番のクラウド環境に至るまでどのように作成されているのかドキュメント化するのです。
ステップ 3: セキュリティ品質を確保する最後の砦を明確化して導入する
従来の製造プロセスで、品質管理はずっと運用の一環でした。しかし、クラウド アプリケーションが登場してから、必ずしもそう ではなくなっています。必要なのは、ソフトウェアの作成に沿って、組織が適切に事前チェックを実行できる場所を特定することで す。すぐれたセキュリティ制御には、手動のコード レビュー作業を補完するため、できる限り多くの自動化機能が含まれている必要 があります。これらは自力では拡張しないからです。
ステップ 4: 認証を検討する
先の 3 つのステップは、組織が開発しているアプリケーション内にセキュリティを構築することに関するものでしたが、組織が利用 するアプリケーションやクラウド インフラストラクチャのセキュリティを検証する必要もあります。この領域では、認証がその役割 を果たします。通常、大規模クラウド プロバイダは、サードパーティによる多数の証明や認証を取得しています。最も一般的なもの として、 SOC2 Typ II と ISO 27001があります。これらは、プロバイダが独自のセキュリティ制御を実装し、独力で検証している状態を識別するものです。
こうした認証では、プロバイダがリスクの全体像を調査および評価している方法を把握できることが重要です。ユーザーがクラウドの使用を拡張し始めると、そのプロバイダがユーザー企業の直接的拡張になるため、このことは重要です。
ここで説明したすべてのステップを利用することで、セキュリティ リーダーは、セキュリティのシフトレフトを実現するだけでな く、セキュリティと開発の統合を確実に進めることができます。クラウドおよびクラウド ネイティブ アプリケーションへの依存が 高まっているのであれば、今こそクラウド サプライ チェーンのセキュリティ戦略を実装する時だということです。