コンテンツに移動
セキュリティ & アイデンティティ

開発の早期段階における投資が後のコストを削減: セキュリティのシフトレフトで最終的な収益を強化

2022年7月22日
https://storage.googleapis.com/gweb-cloudblog-publish/images/Shift-Left-Security.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のインフラストラクチャによるセキュリティのシフトレフト

ソフトウェア開発のライフサイクルでは、「シフトレフト」というコンセプトが広く推奨されてきました。このコンセプトは、開発プロセスの早い段階(左方向に)セキュリティを導入することで、本番環境に移行後(右方向における)ソフトウェアに関するセキュリティ上の欠陥を少なくするというものです。

クラウド セキュリティをシフトレフトすることで、開発サイクルの早い段階で潜在的な構成ミスを特定できます。これが解決されない場合、セキュリティ上の欠陥につながる可能性があります。このような構成ミスを早期に発見することで、本番環境デプロイのセキュリティ対策を強化できます。

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

Google の DevOps Research and Assessment(DORA)は、2016 年の State of DevOps Report の中で、セキュリティを DevOps に統合することの重要性を強調しています。このレポートでは、ソフトウェア開発のライフサイクルにおけるセキュリティ テストの配置について取り上げています。アンケートでは、大部分のセキュリティ テストとツールの使用は、開発ライフサイクル全体で継続的に行われるのではなく、リリースの開発後に行われていることが明らかになりました。そのため、図 1 に示すように、テストで見つかった問題を修正するためには、大きなアーキテクチャの変更と追加の統合テストが必要な場合があり、コストと煩雑さが増す結果となります。たとえば、本番環境におけるセキュリティの欠陥は、GDPR 違反を招き、年間収益全体の最大 4% の罰金を科される可能性があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Figure_1_UWrAtqh.max-600x600.jpg
図 1: 従来のテストパターン

開発フェーズにセキュリティ テストを挿入することで、セキュリティ上の欠陥を早期に特定し、より早く適切な修正ができます。その結果、ポストプロダクションでの欠陥が少なくなり、修正作業やアーキテクチャの変更を減らすことができます。図 2 は、SDLC の早い段階でセキュリティを統合することで、セキュリティの欠陥とそれに関連する修正コストが全体的に減少することを示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Figure_2_2hIaSvk.max-600x600.jpg
図 2: シフトレフト後のセキュリティの状況

2021 年の State of DevOps Report では、2016 年のレポートの内容を発展させ、ソフトウェア開発のライフサイクル全体で自動テストを統合することを推奨しています。自動テストは、開発者のスキルや介入を必要とせず、開発コードを継続的にテストするのに有用です。開発者は迅速にイテレーションを続けることができ、その他の関係者は一般的な欠陥が特定、修正されることを確信できます。

コードからクラウドへ

コード セキュリティに関する DORA の調査結果は、クラウド インフラストラクチャ セキュリティにも応用できます。より多くの組織がワークロードをクラウドにデプロイする中で、クラウド インフラストラクチャのセキュリティと構成をテストすることは重要です。クラウド リソースの構成ミスは、データの盗難につながる恐れがあるセキュリティ インシデントを引き起こす可能性があります。そのような構成ミスの例としては、制限が緩すぎるファイアウォール ルール、VM のパブリック IP アドレス、サービス アカウントやストレージ バケットに対する過剰な Identity and Access Management(IAM)権限が挙げられます。

Google Cloud のさまざまなサービスを活用して、開発プロセスの早い段階でこうした構成ミスを特定し、本番環境でエラーが発生するのを防ぐことで、今後の修正コストや法的罰金の可能性を低減し、お客様の信頼を守ることが可能です。

各種ツールの中で重要なのは、Security Command CenterCloud Build です。Security Command Center では、Google Cloud 組織内の構成ミス、脆弱性、脅威が確認できます。この情報は、クラウド インフラストラクチャ(仮想マシン、コンテナ、ウェブ アプリケーションなど)を脅威から保護する、または、コンプライアンス フレームワーク(CIS ベンチマークPCI-DSSNIST 800-53ISO 27001 など)の潜在的なギャップを特定する際に非常に重要です。

Security Command Center では、セキュリティ オペレーション向けに包括的な可視性を実現する一方で、クラウド プロジェクト レベルでは各開発者向けにセキュリティ検出結果の可視性を提供することで、セキュリティのシフトレフトのサポートをより強化しています。Cloud Build では、クラウドネイティブな CI / CD パイプラインが作成できます。パイプラインにカスタム ヘルスチェックを挿入して、特定の条件(セキュリティ指標など)を評価し、異常が検出された場合にパイプラインを無効にできます。次に、これらのツールを活用した 2 つのユースケースをご紹介します。

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

セキュリティ ヘルス チェッカーでは、Google Cloud プロジェクトのセキュリティ状況を継続的にモニタリングし、プロジェクト メンバーにセキュリティ検出結果を迅速に通知します。図 3 は、開発者がネットワーク、コンピューティング、データベース コンポーネントを使用して Google Cloud 環境とやり取りする様子を示しています。Security Command Center は、プロジェクトの健全性をモニタリングするように構成されています。

Security Command Center で検出結果が特定されると、Cloud Pub/Sub トピックに送信されます。次に、Cloud Functions の関数を使用して、そのトピックにパブリッシュされた検出結果を取得し、インフラストラクチャの開発者によってモニタリングされている Slack チャネルに送信されます。スペル チェッカーを使用するとスペルミスに対して迅速にフィードバックが行われるのと同じように、セキュリティ ヘルス チェッカーでは、デプロイの失敗やポストプロダクションの危険につながる可能性のある Google Cloud プロジェクトにおけるセキュリティの構成ミスについて、迅速にフィードバックを提供します。開発者側で行う追加作業はありません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Figure_3_9ZaTlMz.max-700x700.jpg
図 3: Google Cloud 環境における Security Command Center

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

開発プロセスにおけるセキュリティに関する懸念をタイムリーに通知するために、Security Command Center を使用することに加え、図 4 に示すように Cloud Build と併せて Security Command Center を使用することでセキュリティ チェックを CI / CD パイプラインに統合できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Figure_4_Kl04dRY.max-900x900.jpg
図 4: セキュリティ パイプライン チェッカーのアーキテクチャ

パイプラインは、開発者が git リポジトリにコードをチェックインすることから始まります。このリポジトリは、Cloud Source Repositories にミラーリングされます。ビルドトリガーによってビルドプロセスが開始されます。ビルド パイプラインでは、Security Command Center によってセキュリティの脆弱性を特定するために設けられた、数分の短い待機時間があります。わずかな遅延ですが、最初は望ましくないように思われるかもしれません。しかしその間に行われる分析によって、ポストプロダクションのセキュリティ上の欠陥を減らすことができます。

待機期間終了後、セキュリティ ヘルス チェッカーとしての機能を果たす Cloud Functions の関数が、Security Command Center(図 4 のコネクタ 1)からの検出結果を評価します。バリデータによって許容できないセキュリティ検出結果があると判断された場合、バリデータではパイプラインに失敗の指示を挿入し、ビルドプロセスを終了させます(図 4 のコネクタ 2)。開発者は、失敗したトリガーを把握し、本番環境にコードを正常にデプロイする前にそれらを修正します。これは、2016 年の State of DevOps Report で、セキュリティを DevOps プロセスに統合しなかった組織が、セキュリティのシフトレフトを行った組織に比べて、セキュリティ上の問題の修正に 50% 以上さらに時間を費やしたという調査結果とは対照的なものです。

まとめ

DORA の 2016 年の State of DevOps Report では、開発プロセスの早い段階でセキュリティを導入し、セキュリティの脆弱性を早期に発見して、ポストプロダクションの段階での作業を減らす、セキュリティのシフトレフトの必要性を指摘していました。また、このレポートでは、ソフトウェア開発のライフサイクル全体での自動テストも推奨しています。

Google Cloud でこうした目的を達成するための 2 つの方法について検討しました。セキュリティ ヘルス チェッカーでは、Security Command Center と Slack を使用して開発者にフィードバックを提供し、開発作業を続ける開発者に対して、セキュリティ検出結果を通知します。セキュリティ パイプライン チェッカーでは、Cloud Build パイプラインの一部として Security Command Center を使用し、ビルドプロセス中に脆弱性が特定された場合、ビルド パイプラインを停止します。セキュリティ ヘルス チェッカーとセキュリティ パイプライン チェッカーの実装については、GitHub リポジトリをご確認ください。こうした例が、Google Cloud サービスを使用したシフトレフトのお役に立てれば幸いです。ぜひ皆様の作業にご活用ください。


この記事は、Google Cloud のセキュリティとコンプライアンスのスペシャリストである Jason Bisson、Bakh Inamov、Jeff Levne、Lanre Ogunmola、Luis Urena、Holly Willey と共同で執筆しました。


- Google Cloud セキュリティ & コンプライアンス スペシャリスト Bakh Inamov
- Google Cloud セキュリティ & コンプライアンス スペシャリスト Jeff Levine
投稿先