Google Cloud で OWASP Top 10:2025 のリスクを軽減する

このドキュメントでは、OWASP Top 10:2025 で説明されているアプリケーション レベルの攻撃の防御に役立つ Google Cloud サービスと緩和戦略について説明します。Open Web Application Security（OWASP）Foundation によって作成された OWASP Top 10:2025 は、ソフトウェア開発ライフサイクル（SDLC）における上位 10 個のセキュリティ リスクのリストです。これらのリスクに対する完全な保護を保証するサービスはありませんが、アーキテクチャに対して有効なサービスを適用すると、強力な多層セキュリティ ソリューションを実現できます。

Google インフラストラクチャは、堅牢なセキュリティ制御を使用してサービスを構築、デプロイ、運用できるように設計されています。物理的および運用上のセキュリティ、保存データおよび転送データの暗号化、その他の基盤となるインフラストラクチャの保護は Google によって管理されます。アプリケーションを Google Cloudにデプロイすることで、これらのメリットを継承できますが、特定の攻撃からアプリケーションを保護するためには、さらなる手段を講じなければならない場合があります。

注: Google Cloud は堅牢な境界とランタイムの防御を提供しますが、セキュリティは共同責任です。OWASP のリスクを効果的に軽減するには、ソフトウェア開発ライフサイクル（SDLC）の早い段階でセキュリティを統合する必要があります。デフォルトで安全なコーディング フレームワーク、定期的なデベロッパー トレーニング、プロアクティブな脅威モデリングとともに、次のサービスを使用します。

コンプライアンス マトリックス

次の表に、OWASP Top 10:2025 で特定された上位 10 個のセキュリティ リスクから防御するために利用できる Google Cloud サービスを記載します。

OWASP Top 10:2025 カテゴリ	Primary Google Cloud と Wiz のコントロール
A01: 不完全なアクセス制御	Access Context Manager、Agent Gateway、Agent Identity、Apigee、Google Cloud Armor、Firebase App Check、Firebase セキュリティ ルール、Cloud Next Generation Firewall（Cloud NGFW）、Identity-Aware Proxy（IAP）、Identity and Access Management（IAM）、組織ポリシー サービス、VPC Service Controls、Wiz Cloud
A02: セキュリティの設定ミス	Access Context Manager、Cloud Asset Inventory、Google Security Operations、組織のポリシー、Security Command Center Premium、VPC Service Controls、Wiz Cloud
A03: ソフトウェア サプライ チェーンの障害	Artifact Registry、Assured Open Source Software（Assured OSS）、Binary Authorization、Cloud Build、Cloud Deploy、Cloud Workstations、CodeMender、Wiz Code
A04: 暗号化の失敗	Apigee、Certificate Authority Service、Certificate Manager、Cloud Key Management Service、Cloud Load Balancing、Cloud Workstations、Confidential Computing、組織のポリシー、Secret Manager、Sensitive Data Protection、Wiz Cloud
A05: インジェクション	Apigee、Cloud Armor、CodeMender、Firebase セキュリティ ルール、Cloud Next Generation Firewall（Cloud NGFW）、Model Armor、Security Command Center Premium、VirusTotal、Wiz Code
A06: 安全性が低い設計	Apigee、CodeMender、Mandiant、Wiz Cloud
A07: 認証の失敗	Access Context Manager、エージェント ID、Apigee、Cloud Armor、Cloud Identity、Firebase App Check、Firebase Authentication、Google Cloud Fraud Defense、IAM（Privileged Access Manager、Workload Identity 連携、Workforce Identity 連携）、IAP、Identity Platform、Security Command Center Premium、Secret Manager、Titan セキュリティ キー、Wiz Code
A08: ソフトウェアまたはデータの整合性の失敗	Artifact Analysis、Assured OSS、Binary Authorization、Cloud Armor、Cloud Build、Cloud Deploy、Firebase App Check、Security Command Center Premium、VirusTotal、Wiz Defend
A09: セキュリティ ロギングとアラートの失敗	アクセス承認とアクセスの透明性、Apigee、Google SecOps、Cloud Logging、Cloud Monitoring、Sensitive Data Protection、Wiz Defend
A10: 例外条件の誤処理	Cloud Armor、Cloud Load Balancing、Error Reporting、Model Armor

Google Cloud サービス

以降のセクションでは、コアGoogle Cloud サービスの OWASP Top 10 のベスト プラクティスについて説明します。

アクセスの承認とアクセスの透明性

アクセスの透明性とアクセスの承認により、クラウド プロバイダのアクセスを検証できます。アクセスの透明性を使用すると、Google の担当者が行った各アクセスの理由を記録できます。Access Approval では、お客様のサービスのサポート任務にあたる Google 社員からのアクセス リクエストを確認した後、必要に応じてこれを承認または拒否できます。

A09: セキュリティ ロギングとアラートの失敗に適用されます。

次のベスト プラクティスを確認してください。

• アクセス承認プロセスを自動化します。これを行うには、受信したアクセス承認リクエストのメタデータを Pub/Sub トピックに送信するように Access Approval を構成します。JSON ペイロードを処理のためにカスタム Webhook エンドポイント（認証済みの Cloud Run サービス、Cloud Run functions、エンタープライズ API Gateway など）に push する Pub/Sub サブスクリプションを作成します。
• アクセスの透明性ログを重要なセキュリティ テレメトリーとして扱います。Monitoring でログベースの指標とアラート ポリシーを作成して、Google の担当者が有効な対応するサポート チケットなしで機密性の高いリソースにアクセスした場合に、セキュリティ オペレーション センター（SecOps）にフラグを設定します。
• アクセスの透明性ログを Google SecOps または一元化されたエンタープライズ SIEM に直接エクスポートします。
• コンプライアンス ポリシーを作成して、ログストリームを定期的に監査し、auto_approved 緊急アクセス イベントが文書化された重大度の高いインシデントに関連付けられていることを確認します。
• 暗号制御を行うには、Key Access Justifications を使用して、システムに鍵の復号承認をプログラムでリクエストさせます。

Access Context Manager

Access Context Manager は、Google Cloudのコンテキストアウェア アクセス エンジンです。Access Context Manager を使用すると、IAP、VPC Service Controls、IAM の属性ベースのアクセスレベル（クライアント IP アドレス範囲、デバイスのセキュリティ ポスチャー、地理的位置など）を定義できます。

以下に適用されます。

• A01: 不完全なアクセス制御
• A02: セキュリティの構成ミス
• A07: 認証の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• 組織のアクセス ポリシー用に再利用可能な階層型セキュリティ レベルを構築します。ベーシック アクセスレベルを作成して、標準属性をテストします。複雑な多要素条件の場合は、カスタム アクセスレベルをデプロイして、高度なデバイスの状態とサードパーティ エンドポイントのシグナルを評価します。
• Endpoint Verification または Chrome Enterprise Core を使用して、フルディスク暗号化、アクティブな画面ロック、承認済みのオペレーティング システム バージョンなどのデバイスレベルの制約を適用します。
• VPC Service Controls で価値の高いデータ リポジトリを保護するには、VPC Service Controls の上り（内向き）ルールにアクセスレベルを追加します。サービス アカウント キーが漏洩した場合、攻撃者はキーだけを使用して、承認されていないパブリック IP アドレスや信頼できないマシンから BigQuery や Cloud Storage をクエリすることはできません。
• ゼロトラスト保護をウェブ アプリケーションと VM 管理トンネルに拡張するには、アクセスレベルを IAP で保護されたリソースに直接関連付けます。

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• 特定のフォルダにバインドされたスコープ指定されたアクセス ポリシーを実装して、ローカル ポリシー管理を個々のプロジェクト チームに委任し、変更を組織の他の部分から分離します。
• 孤立した上り（内向き）ルールがサイレント バックドアにならないように、定期的に廃止された IP 範囲、期限切れのパートナー サブネット、古いデバイス属性を確認して削除します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• ユーザー アクセス バインディングを使用して、セッションの最大期間を厳密に設定します。SECURITY_KEY（FIDO2 または WebAuthn）を要求するように再認証ポリシーを構成します。リスクの高い環境に厳しい制約を適用するには、scopedAccessSettings を構成して、機密性の高いアプリケーションのデフォルトのセッション期間をオーバーライドします。

Agent Gateway とエージェント ID

Agent Gateway と Agent Identity は、AI エージェントとエージェント型ワークフロー専用のネットワーク ポリシーの適用、ID ライフサイクル管理、暗号認証を提供します。

以下に適用されます。

• A01: 不完全なアクセス制御
• A07: 認証の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• マルチエージェント システム、外部 MCP ツール、自律型パイプラインを使用する環境では、Agent Gateway を専用のネットワークとポリシー適用ポイントとして使用して、エージェント アクセス制御の失敗を軽減します。
• エージェント ID のきめ細かい認可ポリシーを構成して、ツールのアクセスとデータ取得を、エージェントの特定のワークフローに必要なリソースのみに制限します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• 静的 API キーやパスワードを埋め込むことなく自律型エージェントとツール統合を認証するには、各エージェントにエージェント ID を生成して割り当てます。
• エージェントの認証情報として X.509 証明書を発行するようにエージェント ID を構成します。これらの証明書はトークンの盗難を防ぐのに役立ちます。アクセス トークンが傍受された場合、そのトークンは他の環境では使用できません。

Apigee

Apigee は、API プロキシを使用して、暗号化基準の適用、署名付きペイロードの検証、転送中および保存中のアプリケーション データの暗号化を行う、一元化されたゲートウェイ レベルのメカニズムを提供します。API トラフィックのリバース プロキシ ゲートウェイとして機能する Apigee は、境界チェックと構造チェックを実行して、ペイロードの検証を支援します。Apigee は、強力な ID 境界を確立するために、API 認証、OAuth、JSON Web Token（JWT）検証ポリシーを組み込みで提供しています。Apigee には、ロギング、モニタリング、エラー処理、監査ロギングを行うためのいくつかの方法が用意されています。

以下に適用されます。

• A01: 不完全なアクセス制御
• A04: 暗号化の失敗
• A05: インジェクション
• A06: 安全性が低い設計
• A07: 認証の失敗
• A09: セキュリティ ロギングとアラートの失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• API プロキシを使用して、次の操作を行います。

  • 攻撃者が API リクエスト パスの ID 変数を操作して別のユーザーのレコードにアクセスしようとするリクエストを傍受します。

  • 標準クライアントが制限付きの管理メソッドや高権限のオペレーションを実行できないようにします。

• API 管理プレーンでは、アクセス制御、認証、シークレットの保存を、暗号化された Key Value Map、Secret Manager、Kubernetes Secrets（ハイブリッド デプロイのみ）を使用して適用します。

• OAuth ポリシーと JWT トークンを使用して、署名を検証します。機密性の高いエンドポイントとアクションを、高権限のきめ細かい OAuth スコープ（delete:account や write:billing など）にマッピングします。OAuthV2 ポリシーを使用して、API エントリ ポイントでこれらのスコープを検証し、正しい権限を持たないクライアントに HTTP 403 Forbidden ステータス コードを返します。

• Advanced API Security を有効にして、異常な動作パターンをトラフィックで分析し、セキュリティ アクションを開始します。

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• アプリケーション内のセンシティブ データを暗号化し、トラフィックがバックエンド アプリケーションに到達する前に厳格な暗号検証を適用します。Cloud KMS を使用して、顧客管理の暗号鍵（CMEK）で Apigee 環境を構成します。
• 一方向 TLS と双方向 TLS を使用して、プロトコル レベルで機密情報を暗号化します。サーバー間またはリスクの高いビジネス統合の場合は、Apigee Ingress ゲートウェイで相互 TLS（mTLS）を構成します。
• VerifyJWT ポリシーと VerifyJWS ポリシーを使用して、リクエストが処理される前に、受信トークンに有効な暗号署名があることを要求します。標準の OAuth 手法を使用し、HMAC、ペイロード ハッシュ、ステートまたはノンスの検証、Proof Key for Code Exchange（PKCE）を実装して、各リクエストを暗号的に強化することを検討します。
• センシティブ データをマスクして、Apigee Debug ツールを使用するときにデータが暗号化されて非表示になるようにします。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• Apigee の脅威保護ポリシーをデプロイして、入力パラメータをサニタイズし、ゲートウェイ レイヤで SQL、NoSQL、コマンド インジェクションの試行をブロックします。
  • JSONThreatProtection
  • XMLThreatProtection
  • RegularExpressionProtection
  • SOAPMessageValidation

A06: 安全性が低い設計に関するベスト プラクティスは次のとおりです。

• OpenAPI 仕様に照らして、受信リクエストまたはレスポンス メッセージの受信リクエストを OASValidation ポリシーで検証します。
• SpikeArrest ポリシーと Quota ポリシーを実装して、トラフィックの急増とバックエンドの過負荷を軽減します。
• 障害処理ルールを使用して、バックエンド エラー（データベースのクラッシュなど）をインターセプトし、一般的な HTTP レスポンスに書き換えます。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• デベロッパー向けの API に API キー検証を実装して、Apigee がクライアント アプリケーションの API キーが存在し、有効で、リクエストされた API リソースにアクセスする権限があるかどうかを確認できるようにします。
• セッション トークンの盗難とリプレイ攻撃を防ぐには、所有証明（DPoP）の実装をおすすめします。DPoP は、トークンを送信者の公開鍵にバインドして、トークン リプレイを軽減します。
• SpikeArrest のレート制限と reCAPTCHA Enterprise の統合を組み合わせて、トークン生成エンドポイントとログイン エンドポイントを自動化されたブルート フォース攻撃から保護します。

A09: セキュリティ ロギングとアラートの失敗に関する次のベスト プラクティスを確認してください。

• 構造化された API トランザクション メタデータを Logging またはサードパーティの SIEM に非同期でストリーミングします。レスポンスがクライアントに配信された後に実行される PostClientFlow に MessageLogging ポリシーをアタッチします。
• プラットフォームの監査ログを一元化して、API プロキシ、認証情報、デプロイ環境に対する変更を追跡します。不正なプロキシ変更が検出されないようにするには、Apigee を Cloud Audit Logs と統合します。詳細については、Apigee 監査ロギングと Apigee API Management 監査ロギングをご覧ください。
• Monitoring で Advanced API Security アラートを構成して、自動スクレイピング キャンペーン、認証情報の不正使用、セキュリティ スコアの回帰を SecOps チームに通知します。
• ログ メッセージ テンプレートで、ユーザーが指定した変数を escapeJSON() 関数でラップしてサニタイズします。
• ログ メタデータを外部 SIEM にストリーミングする場合は、TLS 経由の Syslog（TCP ポート 6514）を使用して転送中のデータを暗号化するように MessageLogging ポリシーを構成します。

Artifact Registry と Artifact Analysis

Artifact Registry は、組織がコンテナ イメージと言語パッケージを 1 か所で管理できる場所です。Artifact Analysis は、Artifact Registry に保存されているアーティファクトの統合された脆弱性スキャン、ソフトウェア部品構成表（SBOM）の生成、メタデータ ストレージを提供します。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A08: ソフトウェアまたはデータの整合性の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• クリーンアップ ポリシーを構成して、バージョンなし、タグなし、または古いリリース候補イメージを事前定義された保持期間後に削除することで、攻撃対象領域を縮小し、脆弱なレガシー イメージのデプロイを防ぐことができます。
• パブリック レジストリよりも内部アーティファクト リポジトリを優先するアップストリーム リポジトリの優先度で仮想リポジトリを構成して、依存関係の混乱攻撃から保護します。
• 不変のイメージタグを適用するか、暗号ダイジェスト（sha256:...）で厳密にデプロイして、タグ変更攻撃を防ぎます。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Artifact Analysis で自動脆弱性スキャンと SBOM 生成を有効にして、デプロイ前に重大な CVE を検出します。
• Artifact Analysis のメタデータを Binary Authorization の証明書と統合して、セキュリティしきい値に違反するイメージのデプロイをブロックします。

Assured OSS

Assured OSS を使用すると、Google が検証して使用している OSS パッケージを、独自のデベロッパー ワークフローに組み込むことができます。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A08: ソフトウェアまたはデータの整合性の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• Assured OSS をアップストリームとして参照するようにリモート リポジトリを構成します。
• ビルド内のオープンソース ライブラリに有効な Google 署名と検証可能な SLSA ビルドの来歴レコードが含まれていることを確認します。Cloud Build で品質ゲートを構成して、アプリケーション バイナリをコンパイルする前にこれらの証明書を検証します。
• Cloud Workstations ベースイメージのパッケージ マネージャー（pip.conf、settings.xml、build.gradle など）を、内部の Assured OSS リポジトリのみを指すように構成します。
• Assured OSS によって生成されたメタデータを使用して、オープンソース パッケージで新たに開示された CVE が特定のデプロイ コンテキストで悪用可能かどうかを判断します。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Artifact Registry で 仮想アップストリーム リポジトリを構成して、Google 検証済みの暗号署名を適用することで、ビルド パイプライン全体でパッケージの完全性を高めます。
• Assured OSS プレミアム ティア（Security Command Center Premium の一部）を使用して、リポジトリのプロビジョニングを自動化し、厳選された JavaScript（npm）パッケージにアクセスして、パッケージ メタデータと脆弱性通知にアクセスします。

Binary Authorization

Binary Authorization はコンテナの整合性を検証して、信頼できるコンテナ イメージのみがデプロイされるようにします。証明書の有無に基づいてデプロイを許可または拒否するポリシーを作成できます。Binary Authorization はクラスタレベルでポリシーを適用するため、環境ごとに異なるポリシーを構成できます。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A08: ソフトウェアまたはデータの整合性の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• 一意の不変の SHA-256 暗号化ダイジェスト（@sha256 など）でコンテナ イメージを参照して適用するように、デプロイ パイプラインを構成します。
• GKE クラスタに Binary Authorization 継続的検証をデプロイして、アクティブな Pod をプラットフォーム ポリシーに照らしてモニタリングし、実行中のコンテナが準拠しなくなった場合に Logging でアラートを生成します。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Cloud Build または GitHub Actions パイプラインで自動証明書生成を適用します。イメージが本番環境に近づくにつれて、順次検証ゲートを通過するように、段階的な構成証明要件を作成します。
• 重大度の高い本番環境のインシデントの場合は、ブレークグラス緊急デプロイを有効にします。ブレークグラス監査ログイベントで Monitoring アラート ポリシーを構成して、アドミッション バイパスが発生したときに SecOps チームに通知します。

CA Service と Certificate Manager

Certificate Authority Service（CA Service）は、プライベート認証局（CA）のデプロイと管理を簡素化します。Certificate Manager は、Cloud Load Balancing と Cloud CDN の TLS 証明書の一元的なプロビジョニング、更新、管理を提供します。

A04: 暗号化の失敗に適用されます。

次のベスト プラクティスを確認してください。

• CA Service を使用して、プライベート証明書の発行とライフサイクル管理を自動化します。Cloud HSM でバックアップされたルート CA と中間 CA をデプロイして秘密鍵を保護し、証明書テンプレートを使用して暗号ポリシー（最小鍵長や許可される拡張鍵の使用など）を適用します。
• Cloud Audit Logs を有効にして、リスクの高い管理イベント（CA の取り消し、ポリシーの更新、証明書リクエストの急増など）をモニタリングします。アラートを Google SecOps に転送して、潜在的なインサイダー脅威や侵害された CI/CD パイプラインを検出します。
• DNS 認証とペア設定された Google マネージド証明書を使用するように Certificate Manager を構成します。Certificate Manager は、ドメインの所有権を検証し、X.509 証明書を発行し、有効期限の 30 日前に更新を処理します。
• 証明書マップをターゲット HTTPS プロキシに関連付けて、プロキシの再起動やロードバランサの再構成を必要とせずに、証明書の動的な選択と証明書のローテーションを有効にします。
• 内部マイクロサービスまたはハイブリッド ロード バランシングの場合は、プライベート CA Service CA プールからプライベート証明書を直接発行するように証明書マップを構成します。
• 受信した Server Name Indication（SNI）リクエストを特定の証明書に照合するように証明書マップを構成します。

Cloud Asset Inventory

Cloud Asset Inventory を使用すると、 Google Cloud で孤立した IT インフラストラクチャや未承認の IT インフラストラクチャをモニタリングできます。

A02: セキュリティの構成ミスに適用されます。

次のベスト プラクティスを確認してください。

• 通知を設定して、保護が不十分なリソースの予期しない実行や、古いソフトウェアの使用についてアラートを発します。
• IAM Policy Analyzer を使用して、allUsers 権限を持つ公開ストレージ バケット、権限が過剰なサービス アカウント ロール、孤立した ID など、構成ミスのあるアクセス制御を検出します。
• アセット スナップショットを BigQuery にエクスポートして、インフラストラクチャ構成を定期的に監査し、マルチプロジェクト環境全体でベースライン コンプライアンス レコードを維持します。

Cloud Armor

Cloud Armor は、 Google Cloud ネットワークのエッジにデプロイする適応型ウェブ アプリケーション ファイアウォール（WAF）です。DDoS 攻撃を防ぎ、SQLi または XSS インジェクション ペイロードをブロックします。Cloud Armor には、OWASP トップ 10 の脆弱性から保護し、認証エンドポイントの攻撃対象領域を制限し、不正使用された認証情報をブロックするための事前構成済み WAF ルールが含まれています。

以下に適用されます。

• A01: 不完全なアクセス制御
• A05: インジェクション
• A07: 認証の失敗
• A08: ソフトウェアまたはデータの整合性の失敗
• A10: 例外条件の誤処理

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• evaluatePreconfiguredWaf('lfi-stable') などの事前構成済み WAF ルールを適用して、ローカル ファイル インクルードとパス トラバーサル攻撃をブロックします。
• origin.region_code 属性を使用して、発信元の国コードに基づいて受信トラフィックを照合するセキュリティ ポリシー ルールを構成することで、地理的アクセス制御（ジオフェンシングとも呼ばれます）を適用します。
• 脅威インテリジェンス フィードを使用して、既知の悪意のある IP アドレスをブロックします。
• 一致ルールを作成して、機密性の高い URL（/admin、/login、/config など）への外部アクセスを制限します。
• ロードバランサで Cloud Armor パス正規化を有効にします。これにより、Cloud Armor はセキュリティ ポリシーを評価する前に、受信 URL をデコードして標準化します。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• ネットワーク エッジで SQL インジェクション（sqli-v422-stable）、クロスサイト スクリプティング（xss-v422-stable）、PHP コマンド インジェクション（php-v422-stable）、Java インジェクション（java-v422-stable）を検出してブロックします。
• 事前構成済みの WAF ルールをさまざまな機密レベルに調整して、トラフィックを積極的に拒否するようにルールを構成する前に、誤検出に対処します。
• 事前構成済みのリモートコード実行（RCE）ルール（rce-v422-stable）とリモート ファイル インクルード（RFI）ルール（rfi-v422-stable）を有効にして、複雑なコマンド インジェクション手法を検出します。
• SQL または PHP をターゲットにした攻撃以外のインジェクション攻撃については、カスタムルールを作成します。カスタムルールを使用すると、プロトコルの特定のキーワードまたはエスケープ パターンがリクエストパスまたはクエリで使用されている場合に、リクエストをブロックできます。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• 認証エンドポイントと管理エンドポイントへのアクセスを制限して、承認済みの IP アドレスまたは国のみにアクセスを許可します。
• evaluatePreconfiguredWaf を有効にすると、セッション状態の脆弱性やセッション ハイジャックを悪用するように設計されたリクエストをインターセプトしてブロックできます。
• securityPolicies.patchRule API を使用して、ネットワーク エッジでクエリ文字列またはヘッダーに不正使用されたパラメータを含む受信リクエストをブロックします。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• 信頼できないソースからハイリスクのシリアル化されたオブジェクトを受け入れるエンドポイントを、次のような拒否ルールを使用して、信頼できる IP アドレスのセットに制限します。

  request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')
  

• カスタムルールをデプロイして、リクエスト本文のキーワードを検査し、言語固有の実行パターンと安全でないデシリアライズ シグネチャを検出します。

A10: 例外条件の誤処理に関する次のベスト プラクティスを確認してください。

• セキュリティ ポリシーで Google Cloud Armor Adaptive Protection を有効にして、通常のトラフィック パターンをベースライン化し、L7 の異常に関するアラートを構成し、攻撃シグネチャを使用してターゲット WAF ルールを生成します。
• 重要なエンドポイント（/login、/checkout、検索 API など）で Cloud Armor のレート制限ルールを構成します。レート制限ルールは、クライアント IP または HTTP ヘッダーごとにリクエストを調整し（たとえば、クライアントを 1 分あたり 100 リクエストに制限）、HTTP 429 Too Many Requests ステータス コードを返します。
• Cloud Armor セキュリティ ポリシーで、優先度が最も低いデフォルト ルールを Deny（ステータス コード: 403 または 404）に設定します。

Cloud Build と Cloud Deploy

Cloud Build と Cloud Deploy は、Google Cloud上で統合された安全な継続的インテグレーションと継続的デリバリー（CI/CD）パイプラインを提供します。Cloud Build は、検証可能な SLSA のprovenanceと暗号証明書を使用してアーティファクトをビルドします。Cloud Deploy は、GKE と Cloud Run 全体で段階的なロールアウト、ターゲットの承認、自動検証を管理します。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A08: ソフトウェアまたはデータの整合性の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• cloudbuild.yaml ファイルで requestedVerifyOption: VERIFIED を設定して、検証可能な来歴を要求します。
• 機密性の高いエンタープライズ ビルド用に、プライベート VPC ネットワークとピアリングされた Cloud Build プライベート プールをデプロイします。
• 専用のユーザー管理サービス アカウントで実行するようにビルドトリガーを構成します。これらのサービス アカウントには、必要な最小限の IAM 許可権限（Artifact Registry 書き込み（roles/artifactregistry.writer）、ログ書き込み（roles/logging.logWriter）など）のみを付与します。
• ステージング環境または本番環境をターゲットとする Cloud Build トリガーで手動承認を必須にする。
• ビルド パイプラインがリリースのみを作成できるように、CI ビルドツール（Cloud Build、GitHub Actions、GitLab など）を Cloud Deploy Releaser（roles/clouddeploy.releaser）ロールに制限します。
• 手動承認を必須にするには、ステージング ターゲットと本番環境ターゲットで requireApproval: true を使用して配信パイプライン マニフェスト（delivery-pipeline.yaml）を構成します。
• ターゲット固有のサービス アカウント（ステージング Namespace に制限された権限を持つサービス アカウントと、本番環境用の監査済みの別のサービス アカウントなど）を使用して実行環境を構成します。
• カスタムフックをデプロイして、ロールアウト ライフサイクル中にアウトオブバンド セキュリティ アサーションを実行します。事前デプロイ フックを使用して、ターゲット クラスタがコンプライアンス ベースラインを満たしているかどうかを確認し、事後デプロイ フックを使用して、ライブ コンテナ エンドポイントに対する自動脆弱性スキャンを開始します。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Cloud Build を Cloud KMS および Artifact Analysis と統合して、単体テストと静的分析テストが正常に完了したときに暗号証明書を作成して署名します。
• cloudbuild.yaml のビルダー ステップで、不変の暗号 SHA-256 ダイジェスト（golang@sha256:... など）を使用します。
• ビルド構成は、ブランチ保護ルール（pull リクエストに対する 2 人のレビューの義務付けなど）で保護されたバージョン管理リポジトリに保存します。ユーザー管理のサービス アカウントを使用して、トリガー変更権限を承認済みのプラットフォーム管理者に制限します。
• CI パイプラインがステージングと本番環境の間でマニフェストを変更できないようにしながら、同一の事前レンダリングされたデプロイ マニフェストと不変のコンテナ イメージ ダイジェストをターゲット ステージ間でプロモートします。
• skaffold.yaml マニフェスト内で自動化されたデプロイ検証タスクを定義します。Cloud Deploy は、Pod がデプロイされた後にこれらの検証コンテナを実行して、動的ヘルスチェック、統合テスト、API コントラクト アサーションを実行します。
• カナリア デプロイ戦略を使用します。Skaffold 検証テストが失敗した場合、またはカナリア フェーズ中にモニタリングで異常しきい値が検出された場合、Cloud Deploy はロールアウトを停止し、トラフィックを最後に確認された正常なリリース バージョンにロールバックします。
• Binary Authorization ポリシーを適用するように GKE クラスタと Cloud Run を構成します。Cloud Deploy がマニフェストを適用すると、ターゲット アドミッション コントローラはコンテナ イメージのダイジェストを暗号で検証し、信頼できないアーティファクトを拒否します。

Cloud Identity と Titan セキュリティ キー

Cloud Identity は、 Google Cloudと Google Workspace 全体で ID、認証情報のライフサイクル、アクセス管理を一元的に提供します。Titan セキュリティ キーは、FIDO2 または WebAuthn 標準に基づく公開鍵暗号を使用する、ハードウェア ベースのフィッシング耐性のあるセキュリティ デバイスです。

A07: 認証エラーに適用されます。

次のベスト プラクティスを確認してください。

• 中間者（PITM）フィッシング攻撃から保護するため、2 段階認証プロセス（2SV）を構成し、許可される方法を [セキュリティ キーのみ]（FIDO2、WebAuthn、Titan セキュリティ キー）に設定します。
• 自動プロビジョニングとともに、企業 ID プロバイダを使用して SAML 2.0 または OIDC ベースのシングル サインオン（SSO）を構成します。
• Google Cloud セッションの長さのポリシーを低い最大しきい値に設定して、ユーザーに定期的な再認証を強制します。
• Titan セキュリティ キーをパスキーとして登録してパスワードレス認証を有効にすると、総当たり攻撃や認証情報の漏洩のリスクを大幅に軽減できます。
• Cloud Identity でセキュリティ キー ポリシーを適用して、特権 ID（プロジェクト オーナー、課金管理者、SecOps チームなど）に Titan セキュリティ キーによる 2FA を義務付けます。リスクの高いユーザーを高度な保護機能プログラムに登録します。

Cloud KMS

Cloud KMS は、互換性のある Google Cloud サービスと独自のアプリケーションの対称暗号鍵と非対称暗号鍵を管理します。対称暗号化、非対称署名、非対称暗号化、MAC 署名用の暗号鍵を生成、使用、ローテーション、破棄できます。

A04: 暗号化の失敗に適用されます。

次のベスト プラクティスを確認してください。

• Cloud KMS Autokey を使用して、プロビジョニングと割り当てを自動化します。Autokey を使用する場合、キーリング、鍵、サービス アカウントを事前にプロビジョニングする必要はありません。代わりに、鍵とキーリングはリソース作成の一環としてオンデマンドで生成されます。
• Cloud KMS 鍵を使用して、ペイロードがストレージ バケットまたはデータベースに送信される前に、機密性の高いペイロードを暗号化します。Cloud KMS API またはクライアント ライブラリを使用して、クライアントサイド暗号化に Cloud KMS 鍵を使用できます。
• 転送中にチェックサムを検証して、エンドツーエンドのデータの完全性を検証します。
• 厳格なコンプライアンスと規制のワークロードについては、Cloud HSM を使用して暗号オペレーションを保存して実行します。Cloud HSM は、FIPS 140-3 レベル 3 検証済みのハードウェア セキュリティ モジュールに鍵を保存します。
• 設定された期間（90 日ごとなど）で鍵の自動ローテーション スケジュールを構成します。

Cloud Load Balancing

Cloud Load Balancing は、ユーザー トラフィックを複数のバックエンド インスタンスとリージョンに分散する、完全に分散されたソフトウェア定義のマネージド サービスです。

以下に適用されます。

• A04: 暗号化の失敗
• A10: 例外条件の誤処理

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• ロードバランサのフロントエンドにカスタム SSL ポリシーを構成して割り当て、ネゴシエーションを TLS 1.3 または安全な TLS 1.2 プロファイルに制限し、弱い暗号スイートを無効にします。

A10: 例外条件の誤処理に関する次のベスト プラクティスを確認してください。

• カスタム エラー レスポンス ページを使用して外部アプリケーション ロードバランサを構成し、バックエンド エラーコードをインターセプトして、標準化された HTML または JSON エラー レスポンスを提供します。
• クロスリージョン フェイルオーバーを備えたマルチリージョン バックエンド サービスをデプロイして、停止や未処理のシステム クラッシュが発生した場合に、トラフィックをセカンダリ リージョンに転送できるようにします。

Google Cloud Observability（Logging、Monitoring、Error Reporting）

Google Cloud Observability は、Logging によるフルスタック ログ管理、Monitoring による指標とアラート、Error Reporting によるリアルタイムのアプリケーション クラッシュ トラッキングを提供します。

以下に適用されます。

• A09: セキュリティ ロギングとアラートの失敗
• A10: 例外条件の誤処理

A09: セキュリティ ロギングとアラートの失敗に関する次のベスト プラクティスを確認してください。

• 機密データを保存する価値の高いデータ リポジトリ（Cloud Storage、BigQuery、Spanner など）に対して、データアクセス ログを有効にします。データアクセス ログを使用すると、機密データの読み取り、書き込み、クエリの各イベントを監査できます。
• カスタム ロギング バケットにバケットロックと保持ポリシーを適用して、攻撃者や権限のない管理者がログを削除して痕跡を隠すのを防ぎます。
• 集約シンクを使用して、ログエントリを照合し、SecOps チーム向けの一元的なリポジトリにルーティングします。インターセプト集約シンクを構成して、データアクセス ログなどの大容量ログが複数の場所に保存されないようにします。
• 権限拒否 IAM エラー、予期しない API キーの作成、ファイアウォール構成の突然の変更など、侵害の重大な指標に対してログベースのアラート ポリシーを構成します。
• ログ エクスプローラまたは Monitoring でログベースのアラート ポリシーをデプロイします。不正な IAM ポリシーの変更や KMS 鍵の取り消しなど、重大度の高いイベントを対象とする完全一致フィルタを指定して、一致するログエントリが取り込まれたときにインシデント通知が生成されるようにします。
• Logging でログベースのカウンタ指標を作成して、一致するログエントリを時系列データに変換します。次に、レートが特定のしきい値を超えた場合（たとえば、5 分間に 50 回を超えるログイン試行の失敗）にインシデントを開始する指標ベースのアラート ポリシーを Monitoring で作成します。
• Cloud Logging API への管理呼び出しをモニタリングし、予期しないログ エクスポート シンクの変更やバケットの削除についてアラートを送信するログベースのアラート ポリシーを構成します。
• 明確なドキュメント テンプレートを使用して通知チャンネルを構成します。ログ エクスプローラのクエリへの直接ディープリンク、オンコール エンジニアの標準運用手順書（SOP）、インシデントの迅速な封じ込めに役立つ明確な修復手順を含めます。

A10: 例外条件の誤処理に関する次のベスト プラクティスを確認してください。

• Error Reporting SDK をアプリケーション コードに直接統合するか、構造化された JSON 例外形式を解析するように Logging を構成します。
• 新しい例外クラスが表示されたときに SecOps チームに通知するように、Error Reporting 通知チャネルまたは Monitoring アラート ポリシーを構成します。

Cloud NGFW

Cloud NGFW は、North-South トラフィックと East-West トラフィックに対してステートフル インスペクションとレイヤ 7 アプリケーション制御を可能にするマネージド ファイアウォール サービスです。

以下に適用されます。

• A01: 不完全なアクセス制御
• A05: インジェクション

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• グローバル ネットワーク ファイアウォール ポリシーと IAM で管理されるリソースタグを使用してネットワーク マイクロセグメンテーションを適用し、バックエンド アプリケーション ティアを分離して、サブネット間の東西通信を制限します。
• ファイアウォール ルールで Google が管理する脅威インテリジェンス リストを使用して、既知の悪意のあるアクター、C2 サーバー、不正使用されたボットネットから発信される上り（内向き）接続をブロックします。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• SQL インジェクション、OS コマンド インジェクション、リモートコード実行エクスプロイト シグネチャに一致する脅威を拒否するセキュリティ プロファイル グループを使用して、侵入検知および防止サービスを構成します。
• Cloud NGFW TLS インスペクションを構成して、インバウンドとアウトバウンドの HTTPS トラフィックを復号し、IPS 挿入シグネチャ チェックをプレーン テキスト ペイロードに適用し、バックエンドに配信する前にセッションを再暗号化します。
• バックエンド データベースと Compute サブネットに FQDN ベースの外向きファイアウォール ルールを適用します。承認済みの事前定義された外部ドメインへのアウトバウンド接続を制限して、脆弱なアプリケーションが不正なリバースシェルを作成するのを防ぎます。
• 脅威防止プロファイルでファイアウォール ルールのロギングを有効にし、これらのログを Google SecOps に転送して、ブロックされたネットワーク インジェクション シグネチャとホストレベルのテレメトリーを関連付け、優先度の高いパッチ適用対象のワークロードを特定します。

Cloud Workstations

Cloud Workstations は、セキュリティとカスタマイズ機能が組み込まれた Google Cloud でマネージド開発環境を提供します。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A04: 暗号化の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• セキュリティ ツール、信頼できるデベロッパー拡張機能、承認済みの言語ランタイムをプリインストールする、Artifact Registry に保存されたカスタム ベース コンテナ イメージを作成します。
• プライベート IP 上り（内向き）と下り（外向き）を使用して、VPC Service Controls の境界内にワークステーション クラスタをデプロイします。
• IAP 経由でセッション トラフィックをルーティングするように Cloud Workstations を構成します。多要素認証（MFA）が有効になっている企業認証情報を使用してデベロッパーが認証を行うことを必須とし、最小権限ロール（Cloud Workstations ユーザー（roles/workstations.user）など）を適用します。
• タイムアウトの上限が低い（たとえば、2 時間操作がないと自動的に停止する）ワークステーション構成を構成します。ワークステーションが再起動すると、Cloud Workstations は最新のセキュリティ パッチが適用されたコンテナ イメージを pull します。これにより、開発者はクリーンな環境で作業できます。

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• CMEK を使用してアタッチされた永続ディスクを暗号化するようにワークステーション構成を構成します。

CodeMender

CodeMender は、専門的な自律型 AI エンジニアリング エージェントです。CodeMender は、新たに発見された脆弱性にパッチを適用し、既存のレガシー コードを書き換えて既存の脆弱性に対処できます。Gemini Enterprise Agent Platform に CodeMender をインストールして構成できます。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A05: インジェクション
• A06: 安全性が低い設計

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• CodeMender CLI をローカル デベロッパー ワークスペースと CI/CD パイプラインに統合して、ターゲット モジュールをスキャンし、悪用可能性を検証し、コードが commit される前にセキュリティの脆弱性を検出します。
• ソフトウェア構成分析（SCA）と依存関係の脆弱性レポートを CodeMender にインポートして、概念実証の脆弱性検証を実行し、デベロッパーのレビュー前に誤検出をフィルタリングします。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• 分離されたローカル サンドボックス内で自動パッチ生成を実行して、脆弱なロジック（入力のサニタイズなど）を書き換えます。プルリクエストを作成する前に、単体テストが合格し、PoC が悪用できなくなったことを確認します。

A06: 安全性が低い設計に関するベスト プラクティスは次のとおりです。

• CodeMender の反復パッチ エンジンを使用して、レガシーまたは安全でないアーキテクチャ コードのロジックをリファクタリングし、明示的なコーディング制約を提供して、アプリケーション モジュール全体で安全な設計パターンを適用します。
• CodeMender で生成された pull リクエストと差分に対して人間による審査を維持し、提案された変更が安全なコーディング ガイドラインに沿っていることを確認します。

Confidential Computing

Confidential Computing は、データが処理されている間、メモリ内のデータを暗号化された状態に保つことで、使用中のデータを保護します。Confidential Computing は、ハードウェア ベースの高信頼実行環境（TEE）を使用して、センシティブ データと暗号鍵がハイパーバイザ、ホスト オペレーティング システム、インフラストラクチャ管理者にアクセスされないようにします。

A04: 暗号化の失敗に適用されます。

次のベスト プラクティスを確認してください。

• 機密性の高いワークロード（PII、財務記録、独自の AI モデルの重みなど）には、Confidential VM または Confidential Google Kubernetes Engine Node を使用します。
• 複数の組織が分析や AI トレーニングのために機密データをプールする必要がある場合（元データを相互に公開することなく）、 Confidential Space を使用して暗号証明とデータ分離を適用します。

Firebase（Firebase Authentication、Firebase App Check、Firebase セキュリティ ルール）

Firebase は、ID、クライアント証明書、データベース アクセスにわたって、デベロッパー向けのセキュリティ制御を提供します。Firebase Authentication はユーザー ID とセッション管理を処理し、App Check はクライアント アプリの完全性を検証し、Firebase セキュリティ ルールは Firestore と Cloud Storage の属性ベースのアクセス制御とスキーマ検証を適用します。

以下に適用されます。

• A01: 不完全なアクセス制御
• A05: インジェクション
• A07: 認証の失敗
• A08: ソフトウェアまたはデータの整合性の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• Firebase セキュリティ ルールで、認証済みユーザーの ID への読み取りと書き込みをスコープ設定します。allow read, write: if true; のような許可型のデフォルト ルールは使用しないでください。
• 管理ロールの場合は、Firebase Admin SDK を使用してユーザーの ID トークンにカスタム クレームを設定し、クライアントサイドのプロファイル書き込みを許可するのではなく、セキュリティ ルールでこれらのクレームを検証します。
• Firebase セキュリティ ルールで App Check を適用して、データベース レイヤで未認証またはスプーフィングされたクライアント アクセスをブロックします。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• 受信ドキュメントのフィールド タイプ、文字列の長さ、オブジェクト サイズをチェックして、データベースに取り込む前に不正な形式または悪意のある書き込みペイロードを拒否することで、セキュリティ ルールで構造ペイロードの検証を適用します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• Identity Platform を使用する Firebase Authentication にアップグレードすると、TOTP を使用した MFA やブロッキング関数などのエンタープライズ保護を有効にできます。
• 機密性の高いアプリケーション データへのアクセスを許可する前に、Firebase Admin SDK を使用してバックエンドで Firebase ID トークンを確認します。
• デバッグ プロバイダを使用して、ステージング環境のデベロッパーと CI/CD パイプライン用に、一時的なスコープ付きデバッグ トークンを生成します。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• ハードウェア格納型証明書プロバイダを強制して、クライアントの完全性を検証します。Android Play Integrity と Apple App Attest を使用するように App Check を構成します。
• Cloud Run と Kubernetes Engine API バックエンドに App Check トークン検証ミドルウェアをデプロイして、スクレイピングされた API キー、自動化されたスクリプト、エミュレートされた環境から発信されたリクエストを拒否します。

Fraud Defense

Fraud Defense は、ウェブの bot、アカウント、トランザクションの保護など、不正行為防止のための統合プラットフォームです。Fraud Defense の一部である reCAPTCHA は、アクセス試行のリスクレベルをスコア付けすることで、bot やその他の形式の自動化および一括トラフィックをフィルタリングします。

A07: 認証エラーに適用されます。

次のベスト プラクティスを確認してください。

• reCAPTCHA を既存の WAF（Google Cloud Armor など）と統合すると、リクエストが認証エンドポイントに到達する前に、自動チャレンジを発行したり、リスクの高い bot トラフィックをブロックしたりできます。
• ログイン、パスワードの再設定、セッション更新のエンドポイントでアカウントを保護します。ユーザーのログイン速度とデバイスのフィンガープリントに基づいて、アカウントの乗っ取り（ATO）のリスクスコアを取得します。
• アウトバウンド SMS メッセージを送信する前に電話番号のリスク プロファイルを評価することで、登録フォームと 2 要素認証フォームで SMS 通信不正利用を防止します。
• 誤検出を減らし、サイト固有のリスク評価モデルをトレーニングするには、定期的にトランザクションのフィードバックにアノテーションを付けて送信します。
• ユーザーのログイン フローとアカウント作成フローでパスワードをチェックし、送信された認証情報がウェブ上のサードパーティのデータ侵害データベースに存在するかどうかを検出します。

Google SecOps

Google Security Operations は、セキュリティ テレメトリー分析（SIEM）、セキュリティ オーケストレーション、自動化、レスポンス（SOAR）、最前線の Mandiant 脅威インテリジェンスを 1 つのプラットフォームに統合したセキュリティ運用プラットフォームです。

以下に適用されます。

• A02: セキュリティの構成ミス
• A09: セキュリティ ロギングとアラートの失敗

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• Security Command Center の検出結果を Google SecOps に取り込み、静的な構成ミス検出結果（PUBLIC_BUCKET_ACL や CMEK_DISABLED など）をライブ ネットワークとファイアウォールのテレメトリーと組み合わせます。
• 封じ込めアクションを実行する自動 SOAR 対応ハンドブックを構築します。
• Gemini を使用して、構成ミスに関するトリアージを迅速に行い、構成ミスのあるアセット、関連する IAM ロール、修復手順の概要を合成したものを取得します。

A09: セキュリティ ロギングとアラートの失敗に関する次のベスト プラクティスを確認してください。

• ログ テレメトリーを統合データモデル（UDM）に正規化して、未加工のログ解析のオーバーヘッドなしで、高速かつ標準化されたマルチクラウド検索と関連付けを実現します。
• YARA-L 2.0 検出ルールを作成して、OS Login の無効化、ロギング シンクの削除、VPC Service Controls 境界の変更などのリスクの高い構成変更をモニタリングします。
• Applied Threat Intelligence のキュレートされた検出を使用して、イベントデータを Mandiant Threat Intelligence データと照合して評価します。
• Google SecOps の Gemini を使用して、自然言語の説明から YARA-L 検出ルールを生成し、複雑なマルチステージ インシデントのタイムラインを要約して、インシデントの概要を作成する。

Identity-Aware Proxy

IAP は、HTTPS と管理 TCP 接続によってアクセスされるアプリケーションの一元的な認可レイヤを作成します。IAP は、Cloud Run、App Engine、Compute Engine、GKE、オンプレミス リソースへのアクセスを許可する前に、ユーザーの ID とコンテキストを検証します。

以下に適用されます。

• A01: 不完全なアクセス制御
• A07: 認証の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• ユーザーの ID、グループ メンバーシップ、リクエストのコンテキストに基づいて、ウェブ アプリケーション、VM、 Google Cloud API、Google Workspace アプリケーションにきめ細かいアクセス制御を適用します。
• Agent Gateway と統合して、エージェント ID のアクセス制御を適用します。
• IAP TCP 転送を使用して、バックエンド インスタンスへの暗号化された HTTPS トンネルを確立し、インターネットに接続する SSH（ポート 22）と RDP（ポート 3389）のエンドポイントを削除します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• IAM または Cloud Identity でプロビジョニングされた ID を使用して、IAP を介して管理インターフェースとウェブ アプリケーションにアクセスするユーザーを認証します。
• アプリケーション レイヤの x-goog-iap-jwt-assertion ヘッダー内の署名付き JWT アサーションを検証します。Google の公開鍵に対して署名を検証し、オーディエンス（aud）クレームがバックエンド サービス ID と一致することを確認します。
• 攻撃者が IAP 認証をバイパスできないようにするには、内部トラフィックと Cloud Load Balancing トラフィックのみを許可し、バックエンド コンテナ URL への直接の一般公開アクセスをブロックするように Cloud Run 上り（内向き）設定を構成します。VM または GKE ノードの場合は、ロードバランサの IP 範囲から発信される上り（内向き）トラフィックのみを受け入れるように VPC ファイアウォール ルールを構成します。

Identity and Access Management

Identity and Access Management（IAM）を使用すると、 Google Cloudのサービスとリソースに対するきめ細かいアクセスを管理できます。IAM には、次のような機能が含まれています。

• Privileged Access Manager: 機密性の高い Google Cloud リソースに対するオンデマンドの一時的な権限昇格を管理します。
• Workload Identity 連携を使用すると、フェデレーション ID を使用してワークロードが Google Cloud リソースにアクセスできます。
• Workforce Identity 連携。これにより、ユーザーはフェデレーション ID を使用して Google Cloud リソースにアクセスできます。

以下に適用されます。

• A01: 不完全なアクセス制御
• A07: 認証の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• 事前定義ロールまたはカスタムロール（基本ロールではない）を使用して、特定のリソースまたはユーザーのニーズに合わせて権限を制限します。
• サービス アカウント ユーザー（roles/iam.serviceAccountUser）ロールとサービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）ロールを付与する権限を制限します。
• IAM Recommender を使用して、組織のアクティブな使用状況ログを分析し、過剰な権限を持つアカウントを削除します。
• ロール バインディングに IAM 条件を記述して、コンテキストアウェア認証を追加し、日付、時刻、送信元 IP アドレスでアクセスを制限します。
• プリンシパル アクセス境界（PAB）ポリシーをデプロイして、プリンシパル セットがアクセスできる組織、フォルダ、プロジェクトを定義します。攻撃者がアクティブなセッションを盗んだ場合や、サービス アカウントに広範な IAM ロールが誤って付与された場合、指定されたリソースが ID の指定された境界外にあると、PAB はアクセスをブロックします。
• 組織レベルまたはフォルダレベルで IAM 拒否ポリシーを適用して、高リスクの権限（iam.serviceAccountKeys.create や resourcemanager.projects.delete など）をブロックします。
• IAM 拒否ルールを構成するときは、exceptionPrincipals リストで専用のブレークグラス セキュリティ グループを宣言します。拒否条件でリソースタグ（resource.matchTag('env', 'prod') など）を使用して、本番環境リソースでの破壊的なアクションをブロックし、開発サンドボックス プロジェクトで開発者の運用上の柔軟性を確保します。

Privileged Access Manager に適用される A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• 重要な管理者ロール（オーナー（roles/owner）、組織管理者（roles/resourcemanager.organizationAdmin）、セキュリティ管理者（roles/iam.securityAdmin）など）を静的 IAM バインディングから Privileged Access Manager 利用資格に変換します。これらの利用資格を構成して、昇格が許可される前に運用上の正当な理由を必要とします。
• 本番環境では、中央の SecOps グループやチームリーダーなどの必須の承認者を使用して、Privileged Access Manager の利用資格ポリシーを構成します。
• Privileged Access Manager の利用資格の最大期間を、現実的な最短の運用期間（標準メンテナンスの場合は 2 時間、ブレークグラス アクションの場合は 30 分など）に構成します。タイマーが切れると、Google Cloud は一時的な IAM ロール バインディングを削除します。
• 非承認の IAM リソース（google_project_iam_policy や google_project_iam_binding ではなく google_project_iam_member や google_folder_iam_member など）を使用して Terraform インフラストラクチャを管理します。この方法により、管理者がインシデントの修復を積極的に行っている間に、Terraform パイプラインが上書きされたり、一時的な Privileged Access Manager ロール バインディングが同期されなくなったりすることを防ぐことができます。
• Privileged Access Manager で Cloud Audit Logs を有効にして、利用資格アクションと有効期限イベントを記録します。これらのログを Google SecOps に取り込んで、複数の時間外昇格リクエストや予期しない地理位置情報からのリクエストの繰り返しなど、疑わしい昇格パターンに関するアラートを生成します。

Workforce Identity 連携に適用される A07: 認証の失敗に関する次のベスト プラクティスを確認します。

• SAML 2.0 または OpenID Connect（OIDC）を使用してワークフォース ID プールをデプロイし、外部 ID プロバイダをGoogle Cloudと連携させます。
• Workforce Identity プールでセッション期間を構成して、フェデレーション ユーザー トークンの有効期間を制限します。
• Workforce Identity プロバイダに属性条件を適用して、マルチテナント IdP トークンの偽造や組織間のユーザーのなりすましを軽減します。
• 外部グループ メンバーシップをマッピングして、フェデレーション グループ プリンシパル セット（principalSet://iam.googleapis.com/.../attribute.group/security-engineers など）に IAM ロールを割り当てます。

Workload Identity 連携に適用される A07: 認証の失敗に関する次のベスト プラクティスを確認します。

• 外部ワークロード用に Workload Identity プールとプロバイダを作成します。有効期間の短い OIDC トークンを使用し、Security Token Service を使用して動的に交換し、数分で有効期限が切れる一時アクセス トークンを取得します。
• ワークロード ID プロバイダに属性条件を適用して、外部マルチテナント プラットフォームが承認されていないリポジトリまたはアカウントからプールに対して認証できないようにします。
• カスタム マッピング属性でフィルタされた特定のプリンシパル セットに IAM ロールを直接バインドします。
• ワークロード アクセスを構成するときは、ターゲット リソースの連携された principalSet:// 識別子に IAM ロールを直接付与します。
• Workload Identity 連携を適用するには、組織に constraints/iam.disableServiceAccountKeyCreation 制約を設定します。

Identity Platform

Identity Platform は、 Google Cloud のお客様向けの顧客 ID とアクセス管理（CIAM）プラットフォームです。Identity Platform は、SDK と API を使用して、マルチプロトコルをサポートする認証を提供します。Identity Platform は、MFA、サードパーティの認証サービスとの統合、監査可能なアクティビティ追跡をサポートしています。

A07: 認証エラーに適用されます。

次のベスト プラクティスを確認してください。

• ユーザーベース全体で MFA を有効にします。TOTP（認証システム アプリ）や WebAuthn（生体認証とセキュリティ キー）など、フィッシング耐性のある方法を優先します。
• beforeCreate トリガーと beforeSignIn トリガーを使用してブロッキング Cloud Run 関数をデプロイし、ユーザーが保存される前、またはトークンが発行される前にカスタム セキュリティ コードを実行します。この方法では、使い捨てメール ドメインのブロック、IP アドレスの制限、メールの確認の義務付けを行うことができます。
• reCAPTCHA Enterprise と統合して、ログイン、登録、パスワードの再設定のリクエストを bot トラフィック、クレデンシャル スタッフィングの試行、自動化された不正使用について評価します。
• パスワード ポリシーを構成して、最小文字数を適用し、特定の文字の複雑さ（数字や記号など）を必須とし、予測可能なシーケンスをブロックします。
• 電話ベースの MFA を使用している場合は、SMS リージョンを構成し、reCAPTCHA SMS 防御を有効にして、ターゲット ユーザーが居住する国コードに確認メッセージを制限します。

Mandiant の AI セキュリティ コンサルティング ソリューション

Mandiant AI Security Consulting Solutions は、開発ライフサイクルの早い段階で、提案されたソフトウェア アーキテクチャ、ビジネス プロセス、クラウド デプロイを評価できます。Mandiant のコンサルタントは、最前線の脅威インテリジェンスをシステム設計に適用することで、コードを 1 行も記述する前に、隠れた論理的な欠陥、信頼境界の欠落、アーキテクチャ上のリスクを特定します。

A06: 安全性が低い設計に適用されます。

次のベスト プラクティスを確認してください。

• 開発を開始する前に Mandiant のコンサルタントに依頼して、アーキテクチャ ワークショップを完了し、最初からセキュリティ制御を実装します。
• 脅威モデリングの専門家と協力して、アプリケーションのデータフロー図を作成します。機密データが信頼境界を越える場所を定義して、厳格な認証、暗号化、検証制御を適用する必要がある場所を特定します。
• アーキテクチャ ワークショップでは、構造化された脅威モデリング フレームワーク（STRIDE など）を使用します。Mandiant のコンサルタントは、実際の悪用可能性とビジネスへの影響に基づいて、発見された設計上の欠陥に優先順位を付けることができます。
• エージェント ワークフローと LLM デプロイの安全な AI ガバナンス ベースラインを確立し、AI エージェント、MCP サーバー、エンタープライズ バックエンド データソース間の明確な信頼境界を定義します。

Model Armor

Model Armor は、LLM のプロンプト、レスポンス、MCP ツール呼び出しをスクリーニングするように設計されています。Model Armor は、生成 AI ペイロードを検査して、プロンプト インジェクション、ジェイルブレイクの試行、悪意のある URL、有害コンテンツ、センシティブ データの漏洩を検出してブロックします。

以下に適用されます。

• A05: インジェクション
• A10: 例外条件の誤処理

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• Apigee Integrationまたは Agent Gateway を使用して、API Gateway レイヤで Model Armor ポリシーをインラインでデプロイし、トラフィックが推論エンジンまたはツール ランタイムに到達する前に、受信プロンプトと送信モデル レスポンスをスクリーニングします。
• 組織レベルまたはフォルダレベルでフロア設定を構成して、個々のプロジェクト チームがバイパスできない必須のベースライン セキュリティ ガードレールを作成します。
• パブリック エンドポイントでのプロンプト インジェクションとジェイルブレイクの検出用に、調整された信頼度しきい値（LOW_AND_ABOVE や MEDIUM_AND_ABOVE など）を使用してカスタマイズされた Model Armor テンプレートを構築します。
• Model Armor テンプレートで悪意のある URL の検出と PDF およびファイルのスキャンを有効にして、埋め込み URL を Google の脅威インテリジェンス データベースと照合します。マルウェアやフィッシング ベクターを含むプロンプトは、実行前に削除します。
• Model Armor テンプレートで Sensitive Data Protection を有効にして、モデルの下り（外向き）トラフィックを検査します。検出されたセンシティブ データがレスポンスの境界を越える前に、プレースホルダに置き換えるように、自動匿名化またはマスキングを構成します。

A10: 例外条件の誤処理に関する次のベスト プラクティスを確認してください。

• MATCH_FOUND 判定をインターセプトして汎用レスポンスを返すようにアプリケーション コードを構成し、システムがデフォルトでプロンプトを実行したり、未加工の例外トレースを公開したりしないようにします。
• Model Armor API 呼び出しでネットワーク タイムアウト、レート制限、未処理の HTTP 5xx エラーが発生した場合に、受信した生成 AI プロンプトを拒否するように、アプリケーション コードにフェイルクローズ（フェイルセキュア）アーキテクチャを実装します。

組織ポリシー

組織のポリシーを使用すると、組織の Google Cloud リソースをプログラマティックに一元管理できます。

以下に適用されます。

• A01: 不完全なアクセス制御
• A02: セキュリティの構成ミス
• A04: 暗号化の失敗

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• constraints/storage.publicAccessPrevention を適用して、allUsers または allAuthenticatedUsers へのアクセスを許可しようとするバケットレベルの IAM ポリシーまたは ACL をオーバーライドします。
• constraints/iam.allowedPolicyMemberDomains を適用して、IAM ポリシー バインディングを検証済みの Google Workspace または Cloud Identity の顧客 ID に厳密に制限します。
• 本番環境フォルダ全体で constraints/iam.disableServiceAccountKeyCreation を適用して、ユーザーがサービス アカウント キーをダウンロードできないようにし、エンジニアリング チームが Workload Identity 連携などの有効期間の短い代替手段を採用するようにします。
• constraints/iam.automaticIamGrantsForDefaultServiceAccounts を適用して、 Google Cloud が制限の緩すぎる編集者（roles/editor）ロールをデフォルトのサービス アカウントに自動的に付与しないようにします。
• 事前定義された制約でカバーされない要件については、カスタム制約をデプロイして、きめ細かいリソース構成を適用します。VM の作成を承認済みのマシン ファミリーのみに制限する、永続ディスクのプロビジョニング サイズを制限する、特定のネットワーク ファイアウォール タグ構成を必須にするなどの方法を検討してください。

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• constraints/compute.requireShieldedVm を使用して Shielded VM を必須にすると、カーネル ルートキット、ブートキット、ファームウェアの改ざんから VM を保護できます。
• constraints/compute.requireOsLogin を適用して、Linux インスタンスで OS Login を使用するように要求します。これにより、SSH アクセスがユーザーの IAM ID と 2SV に直接リンクされます。
• constraints/compute.disableSerialPortAccess を適用して、プロジェクト間のインタラクティブ シリアル コンソール接続をブロックします。
• constraints/compute.skipDefaultNetworkCreation を適用して、デフォルトの VPC ネットワークが作成されないようにします。これにより、チームは専用のサブネットと厳格なファイアウォール ポリシーを使用してカスタム VPC を構築する必要があります。
• constraints/sql.restrictPublicIp を適用して、Cloud SQL インスタンスがプライベート RFC 1918 内部 IP アドレスのみを受信するようにします。また、constraints/compute.vmExternalIpAccess を使用して、VM のパブリック IPv4 アドレスを制限します。
• constraints/gcp.resourceLocations を適用して、リソースの作成を承認済みの Google Cloud リージョンに制限します。

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• CMEK を必須にするには、組織または最上位フォルダに constraints/gcp.restrictNonCmekServices を適用し、ポリシータイプを Deny に設定して、サポートされている Google Cloud サービスを一覧表示します。制約を適用する前に、各ターゲット サービスのサービス エージェントが存在し、関連するキーリングで Cloud KMS CryptoKey の暗号化/復号（roles/cloudkms.cryptoKeyEncrypterDecrypter）ロールが付与されていることを確認します。
• constraints/gcp.restrictCmekCryptoKeyProjects を適用して、鍵の選択を専用の Cloud KMS プロジェクトに制限します。

Secret Manager

Secret Manager を使用すると、アプリケーションとパイプラインは IAM で付与された権限に基づいて名前付きシークレットの値にアクセスできます。有効にすると、Secret Manager とのやり取りによって監査証跡が作成されます。この監査証跡は、フォレンジックやコンプライアンスのニーズに対応するために使用できます。

以下に適用されます。

• A04: 暗号化の失敗
• A07: 認証の失敗

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• CMEK を使用して価値の高いシークレットを暗号化することで、シークレット ペイロードをラップするプライマリ暗号鍵を制御、ローテーション、取り消しできます。
• データの完全性チェックサムを使用して、シークレット バージョンの追加とアクセス時にシークレットのデータの完全性を維持、検証します。
• 地理的なデプロイ ゾーン全体で高可用性と障害復旧を実現するために、複数のリージョンにシークレットを複製します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• API キーなどの機密性の高い値をソースコード、.env ファイル、コンテナ ビルド構成から削除し、認証情報を Secret Manager に保存します。Google Cloud クライアント ライブラリ、GKE Secret Store CSI ドライバ、または Cloud Run シークレット バインディングを使用して、実行時に復号された値を取得します。
• IAM ポリシー バインディングを特定の個々のシークレットに直接適用し、マイクロサービスに必要な特定のシークレットに対してのみ Secret Manager のシークレット アクセサー（roles/secretmanager.secretAccessor）ロールを付与します。
• Secret Manager で自動ローテーション スケジュールを構成します。ローテーション間隔が開始されると、Secret Manager は指定された Pub/Sub トピックに SECRET_ROTATE 通知を公開します。通知を読み取り、新しいシークレット値を生成し、新しいバージョンを Secret Manager に追加して、廃止されたバージョンを破棄するように Cloud Run functions または Cloud Run サービスを構成します。
• Secret Manager で Cloud Audit Logs を有効にして、シークレット バージョンの作成、破棄、ペイロード アクセス イベントを追跡します。これらのログを Google SecOps に転送して、侵害されたサービス アカウントが標準の営業時間外に Secret にアクセスしたり、承認されていない Secret リソースを読み取ろうとしたりするなど、疑わしいアクセス イベントに関するアラートを生成します。

Security Command Center Premium

Security Command Center Premium を使用すると、 Google Cloud環境とウェブ アプリケーションで、セキュリティの構成ミスやアクティブなランタイム脅威（ID と認証の失敗など）を検出して対処できます。Web Security Scanner サービスは、XML 外部エンティティ（XXE）の脆弱性などのアプリケーションの脆弱性をモニタリングできます。このサービスのスキャンは、OWASP トップ 10 コントロールに対応するように設計されています。

以下に適用されます。

• A02: セキュリティの構成ミス
• A05: インジェクション
• A07: 認証の失敗
• A08: ソフトウェアまたはデータの整合性の失敗

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• Compliance Manager を使用して、組み込みのフレームワークを適用します（CIS ベンチマークや NIST など）。これにより、規制のセキュリティ フレームワークと業界ベンチマークに照らしてクラウド構成を評価できます。
• クラウド インフラストラクチャ資格管理を有効にして、クラウド デプロイのリソースにアクセスできる ID を管理し、構成ミスによる潜在的な脆弱性を軽減します。
• Web Security Scanner の結果を確認して修正し、HTTP レスポンス セキュリティ ヘッダーの構成ミス、無効な CORS オリジン ヘッダー、混合コンテンツの配信を修正します。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• Virtual Machine Threat Detection や Container Threat Detection などのサービスを有効にします。これらのサービスは、ハイパーバイザのメモリとカーネル イベントをスキャンして、悪意のあるスクリプト、リバース シェル、マルウェアのインストール（Added Binary Executed と Added Library Loaded 検出器を使用）を検出します。
• 実行中のアプリケーションで クロスサイト スクリプティング（XSS）と SQL インジェクション（SQLi）の欠陥をモニタリングするように Web Security Scanner を構成します。
• Security Command Center の検出結果を Google SecOps またはサードパーティの SIEM に統合して、トリアージとインシデント対応を自動化します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• ブルート フォース: SSH 検出機能と 永続性: IAM 異常付与検出機能を使用して、認証情報ベースの攻撃をキャッチするようにロギング ストリームをモニタリングします。
• 多要素認証またはパスワードレス認証を使用する、API キーにアプリケーション制限を設定する、API キーのローテーションを必須にするのクラウド制御を使用して、MFA が使用されていない場合を検出し、API キーの使用状況をモニタリングします。
• HttpOnly フラグと Secure フラグを使用して HTTP Cookie にセッション トークンを保存するようにウェブ バックエンドを構成して、セッション ID の漏洩の検出結果を修復します。

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Web Security Scanner を構成して、署名ベースの実行バグがないかウェブ エンドポイントをスキャンし、アプリケーションが脆弱な Apache Struts バージョンを実行している場合は、重大度の高い STRUTS_INSECURE_DESERIALIZATION の検出結果を生成します。
• 脆弱なフレームワーク ライブラリのバージョンをアップグレードするか、Assured OSS をデプロイして Google が検証した代替ライブラリをプルすることで、STRUTS_INSECURE_DESERIALIZATION の検出結果を修復します。

Sensitive Data Protection

Sensitive Data Protection を使用すると、バケット、データベース、生成 AI プロンプト、ストリーミング アプリケーション ペイロードに保存されているセンシティブ データを潜在的にスキャンし、意図しない情報の漏洩を防ぐことができます。許可されていないデータが識別された場合、Sensitive Data Protection はそのデータにフラグを設定するか、秘匿化できます。

以下に適用されます。

• A04: 暗号化の失敗
• A09: セキュリティ ロギングとアラートの失敗

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• 機密データの検出を有効にすると、ストレージとデータベースのアセットが継続的にスキャンされ、データ プロファイルが生成され、監査レポートの指標が報告されます。
• フォーマット保持暗号化、暗号ハッシュ化、鍵ベースのトークン化を使用して、機密データを匿名化します。
• 再利用可能な一元管理された匿名化テンプレートをデプロイして、開発チーム全体で一貫した暗号化マスキングと検査ポリシーを適用します。
• プロンプト ペイロードを分析して、機密性の高い企業データや PII が生成 AI トレーニング パイプラインに漏洩するのを防ぎます。

A09: セキュリティ ロギングとアラートの失敗に関する次のベスト プラクティスを確認してください。

• アプリケーション ログを Pub/Sub トピックに送信するように Logging シンクを構成します。Sensitive Data Protection API を使用してログ ペイロードをスキャンして匿名化する Cloud Run サブスクライバーを接続し、クリーンなログを最終的な Logging バケットに書き込みます。
• Logging シンクで除外フィルタを使用して、リスクの高い非構造化ログ（未加工のアプリケーション エラー、ユーザー登録ペイロード、トランザクション ログなど）のみをサニタイズ パイプラインに転送します。

VirusTotal

VirusTotal API は、脅威インテリジェンスとファイル スキャン プラットフォームです。不審なファイル、URL、ドメイン、IP アドレスを分析して、マルウェア、トロイの木馬、悪意のあるペイロードを検出します。VirusTotal API をファイル取り込みパイプラインに統合すると、アプリケーション システムでファイルが処理される前に、信頼できないアップロードをスキャンできます。

以下に適用されます。

• A08: ソフトウェアまたはデータの整合性の失敗
• A05: インジェクション

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• カスタムの YARA-X シグネチャ マッチング ルールをデプロイして、既知の悪意のあるバイナリ パターンとテキスト パターンについて受信ファイル構造をスキャンし、変異したマルウェアの亜種を検出できるようにします。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• VirusTotal Private Scanning モジュールを使用して、機密性の高いアップロードを分離してスキャンし、アップロードされたファイルを第三者と共有しないようにします。
• 取り込みコードに API レート制限と例外処理を実装して、HTTP 429 Too Many Requests ステータス コードをキャッチします。

VPC Service Controls

VPC Service Controls を使用すると、 Google Cloud リソースの周囲に境界を作成して、データ漏洩を防ぎ、サーバーサイド リクエスト フォージェリ（SSRF）攻撃を軽減できます。VPC Service Controls は、上り（内向き）ルールと下り（外向き）ルールで明示的に許可されていない限り、境界を越える API 呼び出しを拒否します。

以下に適用されます。

• A01: 不完全なアクセス制御
• A02: セキュリティの構成ミス

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• サービス境界に重要なサービス（Cloud Storage、BigQuery、Spanner、Agent Platform など）を含めて、承認済みの VPC ネットワークと信頼できる ID への API アクセスを制限します。
• サーバーレス リソースに下り（外向き）境界ルールを構成して、境界外の外部宛先への送信 API 呼び出しによって発生する不正なデータ引き出しをブロックします。
• 承認済みのプロジェクト ソース、ターゲット API、呼び出し元の ID を指定する明示的な上り（内向き）ルールと下り（外向き）ルールを使用して、境界を越えた API アクセスと組織を越えた API アクセスを制限します。

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• プロジェクトを、環境セキュリティ階層（本番環境の境界など）ごとに整理された専用の境界にグループ化します。VPC アクセス可能なサービスを使用して、境界内で呼び出すことができる内部 Google API を制限します。
• サーバーレス ワークロードからのアウトバウンド API リクエストを VPC ネットワーク経由でルーティングします。Cloud Run サービスと Cloud Run functions を構成して、ダイレクト VPC 下り（外向き）またはサーバーレス VPC アクセス コネクタを使用し、上り（内向き）を内部専用に厳密に設定します。
• 企業 IP サブネット、認証済み ID クレーム、Endpoint Verification デバイスの状態シグナルの組み合わせを評価する境界内ルールに、Access Context Manager アクセスレベルをバインドします。
• 緊急インシデント対応用に事前承認済みのブレークグラス管理プロセスを維持し、予期しない境界違反イベントに関するモニタリング アラートを設定します。

Wiz サービス

以降のセクションでは、Google Cloudと統合する Wiz サービスの OWASP Top 10 のベスト プラクティスについて説明します。

Wiz Code

Wiz Code は、クラウド セキュリティをデベロッパー ワークフローと CI/CD パイプラインに拡張します。Wiz Code は、コードとクラウドのテレメトリーを関連付け、Infrastructure as Code（IaC）をスキャンし、依存関係（SCA）を分析し、公開された認証情報を検出し、静的アプリケーション セキュリティ テスト（SAST）を実行します。

以下に適用されます。

• A03: ソフトウェア サプライ チェーンの障害
• A05: インジェクション
• A07: 認証の失敗

A03: ソフトウェア サプライ チェーンの障害に関する次のベスト プラクティスを確認します。

• Wiz CLI を CI/CD パイプラインに統合して、保護されたブランチに重大な CVE、公開されたシークレット、重大な IaC 構成ミスが導入された場合に、プルリクエストの統合をブロックします。
• すべてのビルドの SBOM を生成してエクスポートし、Wiz Cloud でサプライ チェーンの継続的な可視性を維持します。
• Wiz Code IDE 拡張機能をデプロイして、開発者にリアルタイムのフィードバックを提供し、コード commit 前に脆弱なパッケージ、ハードコードされた API キー、構文エラーを検出します。
• CI/CD パイプラインで Wiz Code を CodeMender と統合して、脆弱なサードパーティの依存関係が検出されたときに pull リクエストを生成、テスト、送信します。

A05: インジェクションに関する次のベスト プラクティスを確認してください。

• SAST スキャナが、信頼できないユーザー入力が適切なサニタイズなしでデータベース クエリまたは OS コマンドに流れていることを検出した場合、プルリクエストの統合をブロックします。
• Wiz Code プラグインをデベロッパー IDE に統合して、デベロッパーが安全でない SQL クエリやコマンド実行パターンを連結して入力した場合に、リアルタイム アラートを提供します。
• Wiz Code がインジェクションの欠陥を検出したら、データフロー トレースを CodeMender に転送して、検証済みの修復パッチの下書きを作成します。

A07: 認証の失敗に関する次のベスト プラクティスを確認してください。

• デベロッパーの IDE、ローカルのプリコミット フック、CI/CD パイプラインに自動シークレット スキャンを実装して、公開された認証情報をキャッチします。
• 認証情報の盗難を軽減するには、静的で有効期間の長い認証情報を、動的で有効期間の短いトークンと ID バインド アクセス（Workload Identity 連携や OIDC ベースの認証など）に置き換えます。
• 検出されたシークレットをコード、環境変数、ビルドログから削除する自動インシデント対応ハンドブックを実装します。

Wiz Cloud

Wiz Cloud は、マルチクラウド環境を分析して、セキュリティの構成ミス、センシティブ データ漏洩、ID リスクを特定します。Wiz Security Graph を使用して、Wiz Cloud はインフラストラクチャ レイヤ全体のリスク要因を関連付け、重要な攻撃経路をハイライト表示します。

以下に適用されます。

• A01: 不完全なアクセス制御
• A02: セキュリティの構成ミス
• A04: 暗号化の失敗
• A06: 安全性が低い設計

A01: 不完全なアクセス制御に関する次のベスト プラクティスを確認してください。

• IAM ロールとポリシーにまたがる複雑なマルチホップ権限昇格パスをトレースしてフラグを設定し、攻撃者が横方向に移動したり、権限を昇格させたりする可能性のある場所を特定します。
• ユーザー アカウント、サービス アカウント、AI エージェントにわたるアクティブなアクセス権限を重要なデータストアにマッピングし、過剰な権限を取り消します。
• ID 利用資格の結果をオーケストレーション プラットフォームと統合して、永続的な管理者ロール バインディングをジャストインタイム（JIT）アクセスに置き換えます。
• データの移動をモニタリングして可視化し、本番環境の PII が安全でないステージング環境や開発環境にコピーまたは同期されたことを検出します。

A02: セキュリティの構成ミスに関する次のベスト プラクティスを確認してください。

• Wiz Security Graph を使用して、構成ミスと複数の攻撃要因を関連付け、クラウド構成のリスクを評価して優先順位を付けます。
• 組み込みのコンプライアンス フレームワーク（OWASP Top 10、CIS ベンチマーク、NIST など）を適用して、業界標準に照らしてクラウド構成を測定します。
• Wiz CLI スキャナを CI/CD パイプラインに統合して、デプロイ前にビルドを確認したり、IaC の構成ミスを修正したりします。

A04: 暗号化の失敗に関する次のベスト プラクティスを確認してください。

• 暗号化されていない平文の認証情報、ハッシュ化されていない鍵、センシティブ データを含むデータベースとストレージ バケットの修復を優先します。
• AI トレーニング ディレクトリ、ベクトル データベース、RAG パイプライン全体で Wiz Cloud データ検出を実行し、LLM の取り込み前に独自のデータと PII が秘匿化されていることを確認します。
• 環境をスキャンして管理されていないデータアセットを特定し、冗長なデータを削除して攻撃対象領域を最小限に抑えます。

A06: 安全性が低い設計に関するベスト プラクティスは次のとおりです。

• Wiz Red Agent に、論理アーキテクチャ インターフェースの分析と攻撃パスのシミュレーションを指示して、本番環境へのデプロイ前に安全でない設計上の欠陥を見つけます。
• Wiz Red Agent から CodeMender に検証済みの攻撃チェーン コンテキストを渡し、根本原因を特定して、テスト済みのアーキテクチャ pull リクエストを生成します。

Wiz Defend

Wiz Defend は、クラウドの検出と対応（CDR）、ワークロードのランタイム保護、Kubernetes のアドミッション セキュリティを提供します。Wiz Defend は、コントロール プレーン アクティビティをモニタリングし、ランタイムの異常を検出し、コンテナ アドミッション ポリシーを適用して、自動コンテインメントをトリガーします。

以下に適用されます。

• A08: ソフトウェアまたはデータの整合性の失敗
• A09: セキュリティ ロギングとアラートの失敗

A08: ソフトウェアまたはデータの整合性の失敗に関する以下のベスト プラクティスを確認してください。

• Wiz Defend のアドミッション ルールを構成して、ルート権限でコンテナを実行しようとする Kubernetes デプロイ マニフェスト、ホスト ネットワーク Namespace をリクエストする Kubernetes デプロイ マニフェスト、または privileged: true を有効にする Kubernetes デプロイ マニフェストを検査して拒否します。
• 本番環境で failurePolicy: Fail（フェイルクローズ）を使用して重要なセキュリティ アドミッション Webhook を構成し、Webhook にアクセスできない場合に信頼できないコンテナをブロックします。

A09: セキュリティ ロギングとアラートの失敗に関する次のベスト プラクティスを確認してください。

• ログシンクを使用して監査ログを Pub/Sub トピックにエクスポートし、Wiz Defend がコントロール プレーン アクティビティとワークロード イベントを取り込んで分析できるようにします。 Google Cloud
• GKE クラスタと価値の高い Compute Engine VM に Wiz Runtime Sensor をデプロイして、ランタイムの脅威、メモリ内エクスプロイト、アクティブな侵害を検出します。
• 封じ込めプレイブックを自動化して、不正使用された IAM サービス アカウントを直ちに無効にするか、不正使用されたワークロードを分離します。
• Wiz Blue Agent を使用して、実行時の検出を調査し、ライブ プロセスのテレメトリーと ID コンテキストを関連付けて、根本原因と影響を受けるアセットを特定します。

OWASP Top 10:2025 のコンプライアンスを維持する

Wiz には、ポスチャーを評価してモニタリングできる OWASP Top 10 2025 コンプライアンス フレームワークが含まれています。OWASP Top 10 2025 コンプライアンス フレームワークは、組み込みの Wiz ポリシーを関連する OWASP リスクカテゴリにマッピングし、コントロールが準拠していない場合は検出結果を作成します。コンプライアンス スコアの推移を追跡できます。必要に応じて、ビジネス要件を満たすように OWASP Top 10 2025 コンプライアンス フレームワークをカスタマイズできます。

次のステップ

その他のベスト プラクティスについては、セキュリティのベスト プラクティス カタログをご覧ください。