Google Cloud 上のサプライ チェーンを保護する
Google Cloud Japan Team
※この投稿は米国時間 2022 年 6 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。
ソフトウェアの安全性を確保するには、信頼チェーンを確立し、それを検証、維持する必要があります。この信頼チェーンは、ソフトウェアの開発やデプロイのプロセスの各段階で証明書を生成して確認することで、コードの来歴や起源を確立します。Google では社内開発プロセスで、コードレビュー、コードの来歴の確認、ポリシーの実施により、ソフトウェアのサプライ チェーンと関連するリスクを最小化するセキュリティ レベルを実現しています。こうしたコンセプトは、開発者の生産性向上と密接に関係しています。ソフトウェアのサプライ チェーンにおけるセキュリティのリスクポイントは何でしょうか？また、Google Cloud でそれをどのように軽減できるでしょうか？もう少し詳しく見てみましょう。
ソフトウェア サプライ チェーンのリスクポイント
ソフトウェアの開発およびデプロイのサプライ チェーンは非常に複雑で、ソースコード、ビルド、公開のワークフローに伴う多くの脅威が存在します。ここでは、ソフトウェア開発のサプライ チェーンが直面する一般的な脅威を紹介します。
A. 有害なソースコードのサブミット（開発者の侵害や強要を含む）
B. 管理者権限の取得などによる、ソース管理プラットフォームの侵害
C. サブミットされていないコードからのビルド要求や、動作を変更するビルド パラメータの指定などの、ビルド パイプラインへの悪意のある動作のインジェクション
D. 有害なアーティファクトを生成するためのビルド プラットフォームの侵害（とりわけ多くの CI システムは、同一プロジェクト内での「敵対的マルチテナント」を考慮して構成されていないため、プロジェクトの「オーナー」がチームの知らないうちにビルドを侵害することがあります）。
E. 依存関係を通じた悪意のある動作のインジェクション（同一の攻撃が再帰的に発生する場合も）
F. CI / CD をバイパスした有害なアーティファクトのデプロイ
G. パッケージ マネージャー / 署名プラットフォームの侵害
H. ユーザーを騙し、正規リソースではなく有害リソースを使用させる（タイポ スクワッティングなど）
これらに加えて、移行中のアーティファクトの改ざん、または開発ライフサイクル システムの基礎となるインフラストラクチャの侵害もあります。
Google は社内でどのようにソフトウェアのサプライ チェーンを保護しているか
ソフトウェアのサプライ チェーンを保護するため、Google は社内でいくつかの対策を取っています。
コミュニティ全体がメリットを得られるように、Google Cloud はこのような対策を外部とも共有しています。SLSA（ソフトウェア アーティファクトのためのサプライチェーン レベル）は、サプライ チェーン整合性のためのエンドツーエンドのフレームワークです。これは、Google が社内で行っていることを OSS に合わせて調整したバージョンです。現状では、SLSA は業界の合意によって制定される段階的に採用可能なセキュリティ ガイドラインのセットとなっています。
Google Cloud はソフトウェアのサプライ チェーンの保護にどのように役立っているか
ソフトウェアのサプライ チェーンの保護には、ソフトウェアのライフサイクル全体での証明書の定義、確認、適用が必要になります。仕組みは次のとおりです。
Binary Authorization
ソフトウェア サプライ チェーンのセキュリティで欠かせない Binary Authorization サービスは、証明書とポリシー チェックにより信頼チェーンの確立、確認、維持を行います。通常、暗号署名は、コードやその他のアーティファクトが本番環境に向かう過程で生成されます。デプロイ前に、証明書をポリシーに基づいてチェックします。
Google Cloud でポリシーと証明書を用いて、開発プロセスでアンビエント セキュリティを実現する方法の手順をご紹介します。最初のステップは、自社のサプライ、またはコードの記述に使用するライブラリとフレームワークを理解することです。
コード
オープンソースは多くのソフトウェアで多用されていますが、その依存関係リスクを特定するのは困難な場合があります。この課題に対処するため、Google Cloud はオープンソースのソフトウェア パッケージを探索するためのインタラクティブな可視化サイト、Open Source Insights を先日立ち上げました。Open Source Insights の特長は、複数言語のパッケージについて、その推移的な依存関係グラフや、継続的に更新されているセキュリティ アドバイザリやライセンスなどのデータを 1 か所で表示できることです。Open Source Insights を、オープンソース プロジェクトのリスクスコアを提供するオープンソース スコアカードと組み合わせて使用することで、開発者は何百万ものオープンソース パッケージの中からより良いものを選択できるようになります。
ビルド
コードはチェックインされると、Cloud Build によってビルドされます。ここで、一連の証明書が取得されるとともに、信頼チェーンに追加されます。たとえば、どのタスクを実行したか、どのようなビルドツールやプロセスを使用したか、などの証明書が作成されます。Cloud Build は、ソフトウェア サプライ チェーンのセキュリティ レベルを示す SLSA レベル 1 の達成を支援します。Cloud Build は、ビルド構成のソースをキャプチャします。これは、ビルドがスクリプトによるものであることを検証するために使用できます（スクリプトによるビルドは手動ビルドよりも安全で、これは SLSA 1 の要件となります）。 さらにビルドの来歴やその他の証明書は、イメージのユニークな署名であるコンテナ イメージ ダイジェストを使用し、必要に応じて調べることができます。
Cloud Build は、フルマネージド クラウド サービスです。つまりこのサービスは、開発者のアジリティに加え、ビルドを保護するためのロックダウンされた環境を提供し、ビルドの整合性が損なわれたり、ビルドシステムが危険にさらされたりするリスクを大幅に低減します。
また、データやアクセスを非公開にするため、プライベート・ネットワーク内にセキュリティ境界を適用することもできます。Cloud Build のプライベート プール を利用することで、VPC-SC とプライベート IP がサポートされ、ロックダウンされたサーバーレス構築環境を、自社のプライベート ネットワーク内で活用できるようになります。
テストとスキャン
ビルドは完了すると Artifact Registry に保存され、自動的に脆弱性スキャンが行われます。このステップでは、アーティファクトの脆弱性スキャンの結果が特定のセキュリティのしきい値を満たしているかどうかの証明など、追加のメタデータが生成されます。この情報は、Google の Container Analysis サービスによって保存されます。このサービスは、アーティファクトのメタデータを構造化して整理し、Binary Authorization などのサービスからアクセスできるようにします。
デプロイと実行
イメージの構築、保存、スキャンを安全に行うことで、デプロイの準備は完了します。このとき、サプライ チェーンを通じて取得された証明書は、Binary Authorization によって信頼性が検証されます。強制適用モードでは、証明書が組織のポリシーを満たしている場合にのみ、イメージがデプロイされます。監査モードでは、ポリシー違反がログに記録され、アラートがトリガーされます。Binary Authorization は、GKE と Cloud Run（プレビュー） で利用でき、適切にレビューされ認証されたコードのみがデプロイされることを保証します。検証は、デプロイの時点で終了するものではありません。Binary Authorization は継続的な検証もサポートしており、デプロイ後も定義済みポリシーへの継続的な適合性を保証します。実行中のアプリケーションが既存または新たに追加されたポリシーに適合しない場合、アラートが作成され、ログに記録されます。
ここまで、Google Cloud の現行のサプライ チェーンの機能について紹介してきました。詳しくは、Binary Authorization と SLSA をご確認ください。
#GCPSketchnote をさらにご覧になるには、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter で @pvergadia をフォローしてください。thecloudgirl.dev もぜひご覧ください。
- Google、デベロッパー アドボケイト リード Priyanka Vergadia
