シフトレフト セキュリティを実装する

Last reviewed 2025-02-05 UTC

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則は、ソフトウェア開発ライフサイクルの早い段階で実装してセキュリティ ポスチャーを改善できる実用的な制御を特定するうえで役立ちます。ここでは、予防的なセキュリティ ガードレールとデプロイ後のセキュリティ管理の実装に役立つ推奨事項について説明します。

原則の概要

シフトレフト セキュリティとは、ソフトウェア開発ライフサイクルの早い段階でセキュリティ プラクティスを採用することを意味します。この原則の目標は次のとおりです。

  • システムを変更する前にセキュリティ上の欠陥が生じるのを防ぎます。予防的なセキュリティ ガードレールを実装し、Infrastructure as Code(IaC)、Policy as Code、CI / CD パイプラインでのセキュリティ チェックなどのプラクティスを採用します。 Google Cloudでは、組織のポリシー サービス強化された GKE クラスタなど、他のプラットフォーム固有の機能も使用できます。
  • システムの変更が commit された後、セキュリティ バグを早期に、迅速かつ確実に検出して修正します。コードレビュー、デプロイ後の脆弱性スキャン、セキュリティ テストなどの手法を採用します。

安全性を重視した設計を実装する原則とシフトレフト セキュリティの原則は関連していますが、範囲が異なります。設計によるセキュリティの原則は、システム全体の再構築が必要になるような基本的な設計上の欠陥を回避する際に役立ちます。たとえば、脅威モデリングの演習で、現在の設計に認可ポリシーが含まれておらず、それがないとすべてのユーザーが同じレベルのアクセス権を持つことが明らかになったとします。シフトレフト セキュリティは、変更が適用される前に実装の欠陥(バグや構成ミス)を回避し、デプロイ後の迅速かつ信頼性の高い修正を可能にします。

推奨事項

クラウド ワークロードにシフトレフト セキュリティ原則を実装するには、次のセクションの推奨事項を検討してください。

予防的なセキュリティ管理を導入する

この推奨事項は、次の重点分野に関連しています。

  • ID とアクセスの管理
  • クラウドのガバナンス、リスク、コンプライアンス

予防的セキュリティ制御は、クラウドで強固なセキュリティ ポスチャーを維持するために不可欠です。これらの制御により、リスクを事前に軽減できます。構成ミスやリソースへの不正アクセスを防ぎ、デベロッパーが効率的に作業できるようにし、業界標準と内部ポリシーへの準拠を確保できます。

予防的なセキュリティ管理は、Infrastructure as Code(IaC)を使用して実装すると、より効果的です。IaC を使用すると、変更がデプロイされる前に、インフラストラクチャ コードに対するよりカスタマイズされたチェックを予防的セキュリティ制御に含めることができます。自動化と組み合わせると、予防的セキュリティ制御は CI / CD パイプラインの自動チェックの一部として実行できます。

次のプロダクトと Google Cloud の機能は、環境に予防的制御を実装する際に役立ちます。

IAM を使用すると、権限に基づいて特定のリソースを操作できるユーザーを承認できます。詳細については、IAM を使用した組織リソースのアクセス制御をご覧ください。

組織ポリシー サービスを使用すると、リソースの制限を設定して、構成方法を指定できます。たとえば、組織のポリシーを使用して次のことができます。

組織のポリシーを使用するだけでなく、次の方法でリソースへのアクセスを制限できます。

  • IAM を使用したタグ: 各リソースのアクセス権限を定義するのではなく、リソースのセットにタグを割り当てて、タグ自体のアクセス定義を設定します。
  • IAM Conditions: リソースに条件付きの属性ベースのアクセス制御を定義します。
  • 多層防御: VPC Service Controls を使用して、リソースへのアクセスをさらに制限します。

リソース管理の詳細については、 Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。

クラウド リソースのプロビジョニングと管理を自動化する

この推奨事項は、次の重点分野に関連しています。

  • アプリケーションのセキュリティ
  • クラウドのガバナンス、リスク、コンプライアンス

クラウド リソースとワークロードのプロビジョニングと管理を自動化する場合は、命令型スクリプトではなく、宣言型 IaC を採用すると、より効果的です。IaC はセキュリティ ツールやセキュリティ対策そのものではありませんが、プラットフォームのセキュリティ強化に役立ちます。IaC を採用すると、再現可能なインフラストラクチャを作成し、運用チームに既知の正常な状態を提供できます。また、IaC はロールバック、変更の監査、トラブルシューティングの効率も向上させます。

IaC を CI / CD パイプラインや自動化と組み合わせると、OPA などのツールを使用して Policy as Code などのプラクティスを採用することもできます。インフラストラクチャの変更を監査し、変更がデプロイされる前にインフラストラクチャ コードの自動チェックを実行できます。

インフラストラクチャのデプロイを自動化するには、Config Controller、Terraform、Jenkins、Cloud Build などのツールを使用できます。IaC と自動化を使用して安全なアプリケーション環境を構築できるように、Google Cloud はエンタープライズ基盤のブループリントを提供しています。このブループリントは、Google の推奨プラクティスと構成に沿った独自の設計です。このブループリントでは、Terraform と Cloud Build を使用して Google Cloud トポロジを構成してデプロイする手順を説明します。

エンタープライズ基盤ブループリントのスクリプトを変更して、Google の推奨事項に沿って独自のセキュリティ要件を満たす環境を構成できます。このブループリントと追加のブループリントに基づいて構築することも、独自の自動化を設計することもできます。Google Cloud アーキテクチャ センターには、エンタープライズ基盤ブループリントの上に実装できる他のブループリントが用意されています。これらのブループリントの例を次に示します。

安全なアプリケーション リリースを自動化する

この推奨事項は、アプリケーションのセキュリティという重点分野に関連しています。

自動化されたツールを使用しない場合、一貫したセキュリティ要件を満たすために、複雑なアプリケーション環境のデプロイ、更新、パッチの適用を行うことは容易なことではありません。ソフトウェア開発ライフサイクル(SDLC)用に自動化された CI / CD パイプラインを構築することをおすすめします。自動化された CI / CD パイプラインを使用すると、手動によるエラーをなくすことができます。標準化された開発フィードバック ループが提供されるので、プロダクトの効率的な反復が可能になります。継続的デリバリーは、DORA フレームワークが推奨するベスト プラクティスの一つです。

CI / CD パイプラインを使用してアプリケーション リリースを自動化すると、セキュリティ バグを早期に迅速かつ確実に検出して修正する能力が向上します。たとえば、アーティファクトの作成時にセキュリティの脆弱性を自動的にスキャンしたり、セキュリティ レビューの範囲を絞り込んだり、既知の安全なバージョンにロールバックできます。さまざまな環境(開発環境、テスト環境、本番環境など)に対してポリシーを定義し、検証されたアーティファクトのみをデプロイすることもできます。

アプリケーション リリースを自動化し、CI / CD パイプラインにセキュリティ チェックを組み込むために、 Google Cloud は Cloud BuildCloud DeployWeb Security ScannerBinary Authorization などの複数のツールを提供しています。

SDLC で複数のセキュリティ要件を検証するプロセスを確立するには、Google が定義したソフトウェア アーティファクトのサプライ チェーン レベル(SLSA)フレームワークを使用します。SLSA では、ソースコード、ビルドプロセス、コードの出所のセキュリティ チェックが必要です。これらの要件の多くは、自動化された CI / CD パイプラインに含めることができます。Google がこれらのプラクティスを社内でどのように適用しているかについては、変更に対するGoogle Cloudのアプローチをご覧ください。

アプリケーションのデプロイが承認プロセスに従っていることを確認する

この推奨事項は、アプリケーションのセキュリティという重点分野に関連しています。

攻撃者が CI / CD パイプラインを侵害すると、アプリケーション スタック全体が影響を受ける可能性があります。パイプラインを保護するには、コードを本番環境にデプロイする前に、確立された承認プロセスを適用する必要があります。

Google Kubernetes Engine(GKE)または Cloud Run を使用する場合は、Binary Authorization を使用して承認プロセスを確立できます。Binary Authorization は、構成可能な署名をコンテナ イメージに適用します。これらのシグネチャ(証明書)はイメージの検証に役立ちます。デプロイ時に、Binary Authorization はこれらの証明書を使用して、プロセスが完了したかどうかを判断します。たとえば、Binary Authorization を使用して次のことができます。

  • 特定のビルドシステムまたは CI パイプラインによってコンテナ イメージが作成されたことを確認する。
  • コンテナ イメージが脆弱性署名ポリシーを遵守していることを確認する。
  • コンテナ イメージが次のデプロイ環境(デプロイから QA まで)に昇格するための基準を満たしていることを確認する。

Binary Authorization を使用すると、信頼できるコードのみがターゲット プラットフォームで実行されるように制限できます。

アプリケーションのデプロイ前に既知の脆弱性をスキャンする

この推奨事項は、アプリケーションのセキュリティという重点分野に関連しています。

アプリケーション アーティファクトを本番環境にデプロイする前に、アプリケーション アーティファクトに対して継続的に脆弱性スキャンを実施できる自動化ツールの使用をおすすめします。

コンテナ化されたアプリケーションの場合は、Artifact Analysis を使用して、コンテナ イメージの脆弱性スキャンを自動的に実行します。Artifact Analysis は、Artifact Registry にアップロードされた新しいイメージをスキャンします。このスキャンにより、コンテナ内のシステム パッケージに関する情報が抽出されます。最初のスキャンの後、Artifact Analysis は、Artifact Registry 内でスキャンされたイメージのメタデータに新たな脆弱性がないか継続的にモニタリングを行います。Artifact Analysis は、新しい脆弱性情報と更新された脆弱性情報を脆弱性ソースから受け取ると、次の処理を行います。

  • スキャンしたイメージのメタデータを更新して、最新の状態に保つ。
  • 新しいメモ用の新しい脆弱性オカレンスを作成する。
  • 有効ではなくなった脆弱性を削除する。

アプリケーション コードで既知の脆弱性をモニタリングする

この推奨事項は、アプリケーションのセキュリティという重点分野に関連しています。

自動化ツールを使用して、アプリケーション コードの既知の脆弱性(OWASP Top 10 など)を常にモニタリングします。OWASP Top 10 の緩和策をサポートする Google Cloud プロダクトと機能の詳細については、 Google Cloudで OWASP Top 10:2025 を軽減するをご覧ください。

Web Security Scanner を使用すると、App Engine、Compute Engine、GKE ウェブ アプリケーションの脆弱性を特定できます。このスキャナは、アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラを処理しようとします。クロスサイト スクリプティングコード インジェクション混合コンテンツ、古いライブラリや安全でないライブラリなど、一般的な脆弱性を自動的にスキャンして検出できます。Web Security Scanner は、誤検出を発生させることなく、これらの脆弱性を早期に特定します。

また、GKE を使用して Kubernetes クラスタのフリートを管理している場合、セキュリティ ポスチャー ダッシュボードには、フリートのセキュリティ ポスチャーを改善するための実施可能な独自の推奨事項が表示されます。