Googleが激推しする「セキュリティのシフトレフト」とは？ 効果と方法を解説：Google Cloudツールのユースケースもある

Googleはソフトウェア開発ライフサイクルにおけるセキュリティの「シフトレフト」が重要な理由を発表した。Google Cloud Platform上でシフトレフトを実現するユースケースも示した。

[＠IT]

　Googleは2022年7月9日（米国時間）、ソフトウェア開発ライフサイクル（SDLC）におけるセキュリティの「シフトレフト」が重要な理由を発表した。加えて、同社のクラウドサービス「Google Cloud Platform」（GCP）で提供されているツールを活用し、シフトレフトとともに、SDLCを通じた自動テストを実現するユースケースも紹介した。

　SDLCにおけるセキュリティのシフトレフトは、ソフトウェア開発プロセスの早い段階（左側）でセキュリティを考慮することで、その後の本番環境（右側）におけるソフトウェア関連のセキュリティ不具合を減らそうとする取り組みを指す。

セキュリティのシフトレフトが重要な理由とは

　Google CloudのDevOps Research and Assessment（DORA）チームは、調査レポート「2016 State of DevOps Report」（2016年のDevOpsの現状調査報告）の中で、ほとんどのセキュリティテストとツールは、開発ライフサイクルを通じて継続的に使用されるのではなく、リリース後に使用されていることを明らかにした。

　セキュリティテストとツールのこうした使用状況は、コストや作業負担の増加につながっていた。テストで見つかった問題を修正するために、アーキテクチャの大きな変更や、追加の統合テストが必要になる場合があったからだ。

従来のテストパターン　セキュリティ上の不具合（薄紫線）が作り込まれるフェーズ（本番環境と類似のテスト環境：staging）の後、リリース前までセキュリティチームがツールを使って修正する（青色線）ため、コスト（赤線）がリリース後に急上昇していた（提供：Google）

　セキュリティテストを開発フェーズで実行すると、セキュリティの不具合を早期に発見し、すぐに修正できる。その結果、本番稼働後の不具合が少なくなり、修正作業やアーキテクチャの変更も少なくなる。SDLCの早い段階でセキュリティを統合することで、セキュリティの不具合に加え、関連する修正コストが全体的に減少することを、次の図は示している。

シフトレフト後のセキュリティ状況　セキュリティ上の不具合が作り込まれるフェーズでツールを使ってすぐに修正するため、総コストを低減できる（提供：Google）

　DORAチームは、調査レポート「2021 State of DevOps Report」（2021年のDevOpsの現状調査報告）では、セキュリティをシフトレフトする必要性を訴えるとともに、SDLCを通じて、自動化されたテスト実行を提唱した。

　自動テストは開発者に追加のスキルや介入を必要とせず、開発コードを継続的にテストするのに便利だと、Googleは述べている。こうした自動テストにより、開発者は迅速なイテレーションを続けることができ、他のステークホルダーは、一般的な不具合が特定、修正されているという確信を持てるとしている。

Google Cloudでシフトレフトを実行する具体的な方法は？

　DORAチームが調査で得たコードのセキュリティに関する知見は、クラウドインフラのセキュリティにも適用できる。

　ワークロードをクラウドにデプロイする組織が増える中、クラウドインフラのセキュリティと設定をテストすることが重要になっている。クラウドリソースの設定ミスは、データの盗難につながる可能性があるセキュリティインシデントの原因になり得る。

　こうした設定ミスにはさまざまな例がある、寛容すぎるファイアウォールルールや仮想マシン（VM）のパブリックIPアドレス、サービスアカウントやストレージバケットに対する過剰なIAM（Identity and Access Management）権限の割り当てなどが挙げられる。

　Google Cloudでは、さまざまなサービスの活用によって、開発プロセスの早い段階で設定ミスを特定し、本番環境でのエラーの発生を防ぐことで、将来の修正コストや、法的罰金を科される可能性、顧客の信頼低下を軽減できる。

　こうした目的に使用できるGoogle Cloudの主要なツールとして、「Security Command Center」と「Cloud Build」がある。

　Security Command Centerは、Google Cloudを利用する組織内の設定ミスや脆弱（ぜいじゃく）性、脅威を可視化する。その情報はVMやコンテナ、Webアプリケーションなどのクラウドインフラを脅威から保護する上で、あるいはコンプライアンスの枠組み（CISベンチマークやPCI DSS、NIST 800-53、ISO/IEC 27001など）からの逸脱の可能性を特定する上で重要だ。

　さらにSecurity Command Centerは、クラウドプロジェクトレベルで発見したセキュリティ上の問題を、個々の開発者向けに可視化するとともに、セキュリティオペレーションのためのグローバルな可視化を実現することで、セキュリティのシフトレフトをサポートする。

　Cloud Buildは、クラウドネイティブなCI/CD（継続的インティグレーション／継続的デリバリー）パイプラインの作成機能を提供する。Cloud Buildを使ってパイプラインにカスタムヘルス（健全性）チェックを挿入し、特定の条件（セキュリティ指標など）を評価して異常が検出された場合に、パイプラインを停止することが可能だ。

　これらのツールを活用し、シフトレフトとともに、SDLCを通じた自動テストを実現する2つのユースケースを次に紹介する。

ユースケース1　セキュリティヘルスチェッカー

　セキュリティヘルスチェッカーは、Google Cloudプロジェクトの開発プロセスでセキュリティ状態を継続的にモニタリングし、セキュリティに関する発見をプロジェクトメンバーに速やかに通知するユースケースだ。

　次の図は開発者がGoogle Cloud環境のネットワークやコンピュート、データベースコンポーネントを使用している場合を扱っている。Security Command Centerが「Cloud Pub/Sub」「Cloud Functions」「Slack」と連携し、プロジェクトの健全性を監視している。

Google Cloud環境におけるSecurity Command Center（提供：Google）

　Security Command Centerが何らかの問題を特定すると、Cloud Pub/Subに送信する。そして、Cloud Functionsが公開された調査結果を受け取り、インフラ開発者が監視しているSlackチャンネルに送信する。スペルチェッカーがスペルミスを素早くフィードバックするように、セキュリティヘルスチェッカーは、デプロイの失敗やポストプロダクションの危険につながる可能性のあるGoogle Cloudプロジェクト内のセキュリティ設定のミスについて、迅速にフィードバックする。開発者は設定ミスやパイプラインの動作について細かい注意を払う必要がない。

ユースケース2　セキュリティパイプラインチェッカー

　セキュリティパイプラインチェッカーは、セキュリティチェックをCI/CDパイプラインに統合するユースケースだ。Cloud Buildによるパイプラインの一部としてSecurity Command Centerを使用し、ビルドプロセスで脆弱性が特定されると、ビルドパイプラインを停止する。

セキュリティパイプラインチェッカーのアーキテクチャ（提供：Google）

　図にあるように、開発者がGitリポジトリにコードをチェックするところからパイプラインが始まる。このリポジトリは、「Cloud Source Repositories」にミラーリングされており、ビルドトリガーがビルドプロセスを開始する。ビルドパイプラインには、Security Command Centerがセキュリティ脆弱性を特定する機会を与えるために、数分の待ち時間を設定しておく。このような待機時間は、望ましくないように見えるが、数分間の自動分析によって、本番稼働後のセキュリティ上の不具合を減らすことができる。

　待機期間が終了すると、セキュリティヘルスチェッカーして働くクラウド機能が、セキュリティコマンドセンターからの結果を評価する（図中の《1》）。

　検証の結果、許容できないセキュリティ上の問題があると判断された場合、検証機能がパイプラインに障害指示を差し込み、ビルドプロセスを終了させる（図中の《2》）。開発者はエラートリガーを確認でき、コードを本番環境に正常にデプロイする前に修正することができる。

　これは、「2016 State of DevOps Report」の調査結果とは対照的だ。セキュリティをDevOpsプロセスに統合しなかった組織は、セキュリティに関して「シフトレフト」した組織に比べて、セキュリティ問題の修正に50％以上の多い時間を費やしている。