Google Cloud（GCP）で自社のシステムを運用していると、取引先や監査、社内の方針から「ペネトレーションテスト（疑似的な攻撃による侵入テスト）や脆弱性診断を実施してほしい」と求められる場面があります。このとき最初に迷うのが、テストを始める前にGoogleへ申請や連絡が必要なのか、という点です。
かつてAWSが事前申請を求めていた時期があったため、GCPでも勝手にテストすると利用規約違反になるのではないか、と不安に感じる担当者は少なくありません。実際には、GCPでは自社が管理するリソースを対象とする限り、事前承認なしでペネトレーションテストを実施できます。ただし、守るべき範囲や例外的に手続きが必要なケースはあり、クラウドならではの確認対象も押さえておく必要があります。
この記事では、GCPでペネトレーションテストを行う際のGoogleの規約上の扱いを整理します。あわせて、GCP特有の確認ポイント、自社で実施する場合と専門会社に依頼する場合の進め方・費用相場まで解説し、読み終えたときに自社の着手計画を立てられる状態を目指します。
目次
一括ダウンロードする
Googleへの事前申請・承認は必要か（結論：自社が管理するリソースなら不要）
結論から言うと、GCP上で自社が管理するプロジェクトやリソースを対象にペネトレーションテストを行う場合、Googleへの事前の連絡や承認は不要です。Google Cloudは、公式のよくある質問（FAQ）のなかで、ペネトレーションテストの実施にあたってGoogleへの連絡は必要ない旨を明記しています。
Google Cloud Platform のセキュリティを評価するためにペネトレーション テストを行う際、Google に連絡する必要はありません。（中略）お客様のプロジェクトのみを対象とする必要があります（中略）脆弱性を発見した場合は、脆弱性報奨金プログラムからご報告ください。
クラウドのセキュリティに関するよくある質問｜Google Cloud ヘルプ
AWSがかつて求めていたような事前申請のプロセスは、GCPには存在しません。テスト計画をGoogleへ提出して許可を待つ必要はなく、自社のプロジェクトの範囲内であれば、準備が整い次第すぐに着手できます。この「自社のプロジェクトのみを対象とする」という条件が、後述する守るべき範囲の基本になります。
出典・参考資料（1件）
- 出典：クラウドのセキュリティに関するよくある質問｜Google Cloud ヘルプ（https://support.google.com/cloud/answer/6262505）
不正アクセス禁止法やアカウント停止が心配な場合はどう考えるか
事前承認が不要とはいえ、「許可なく攻撃的なテストをして、不正アクセス禁止法に触れたりアカウントを止められたりしないか」という不安は残ります。ここで鍵になるのが、テストの対象を自社が管理するリソースに限るという原則です。
自社が契約・管理しているプロジェクトやリソースに対して、自社の判断で診断を行うことは、第三者のシステムへ無断で侵入する行為とは性質が異なります。問題になりやすいのは、対象範囲が曖昧なまま他社のサービスや共有基盤に影響を及ぼしてしまうケースです。テストを始める前に、どのプロジェクト・どのリソースを対象にするかを明確に定義し、関係者の合意を書面で残しておくと、後からの説明責任にも対応しやすくなります。
法令や契約上の妥当性についての最終的な判断は、自社の法務・コンプライアンス部門や専門家に確認することをおすすめします。
一方、AWSでは事前申請の扱いや自己診断・ベンダー診断の使い分け、費用の考え方がGCPとは異なります。AWS環境もあわせて点検する予定がある場合は、次の記事でAWS側の進め方を確認できます。
GCPでペネトレーションテストをしてよい範囲・禁止行為と例外的な手続き
ここからは、事前承認が不要という前提のうえで、どこまでやってよく、何に注意すべきか、そして例外的に手続きが必要になるケースを整理します。GCPのテストで守るべき範囲は、Google Cloudの利用規約（Acceptable Use Policy）とセキュリティFAQから読み取れます。全体像は次の図のとおりです。
対象は自社が管理するプロジェクト・リソースに限る
前述のとおり、テストの対象は自社のプロジェクトのみに限る必要があります。Google Cloudの利用規約は、他の利用者のサービスを中断・毀損する行為を禁じています。ペネトレーションテストも、他のGoogle Cloud利用者や共有基盤へ影響が及ばないように設計することが大前提です。
具体的には、検査対象のIPアドレスやリソースを事前に洗い出し、スキャンやエクスプロイトの範囲がそこから外れないよう制御することが重要です。マルチテナントのマネージドサービスを使っている場合は、自社のテナントの範囲にとどまっているかを特に意識しておきましょう。
出典・参考資料（1件）
- 参考資料：ポリシーと規約（Acceptable Use Policy）｜Google Cloud（https://cloud.google.com/terms/aup）
DoS・DDoSのように負荷や影響を広げる手法は避ける
Googleは特定の攻撃手法を名指しで一律に禁止しているわけではありません。判断の軸になるのは、あくまで「他のGoogle Cloud利用者に影響を及ぼさないか」という原則です。
サービス妨害を狙うDoS・DDoSのように、大量の負荷をかけたり影響範囲が広がったりしやすい手法は、自社リソースのみを対象とする原則から外れやすく、共有基盤や他テナントに波及するおそれがあります。
そのため、影響を自社の範囲に閉じると確実には言い切れないDoS・DDoS系の手法は、原則として実施しないのが安全です。どうしても必要な場合に限り、影響範囲を自社に閉じる設計ができると確認したうえで慎重に行います。
Google製品自体の脆弱性は脆弱性報奨金プログラム（VRP）へ報告する
テストの過程で、自社の設定ミスではなく、Google Cloudの基盤やGoogle製品そのものに起因する脆弱性を見つけることがあります。
この場合は、自分でさらに深く検証を進めるのではなく、Googleの脆弱性報奨金プログラム（Vulnerability Reward Program、VRP）を通じて報告します。前掲のセキュリティFAQでも、脆弱性を発見した場合は報奨金プログラムから報告するよう案内されています。
出典・参考資料（1件）
- 参考資料：Google Bug Hunters（脆弱性報奨金プログラム）（https://bughunters.google.com/）
負荷テストでは割り当て（Quota）と上限（Limit）を確認する
ペネトレーションテストと並行して負荷テストを行う場合も、後述するApigeeのような例外を除けば、負荷テストそのものに個別の事前承認が課されるわけではありません。ただし、Google Cloudには各サービスに割り当て（Quota）と上限（Limit）が設定されているため、テスト前に自社プロジェクトの割り当て状況を確認しておきます。
想定する負荷が割り当てを超えそうな場合は、Google Cloudコンソールから割り当ての引き上げをリクエストします。大規模な負荷テストを計画している場合は、事前にGoogleのアカウントチームやカスタマーケアへ相談しておくと、テスト中の予期せぬ制限を避けやすくなります。これはテストの承認を得るための手続きではなく、あくまで任意の相談です。
公式には、ピーク時のイベントに向けた負荷テストの進め方や、Cloud Runなどサービスごとの負荷テストのベストプラクティスが整理されています。
出典・参考資料（3件）
- 参考資料：ピーク時のイベントに向けた負荷テストの実施（Conduct load testing）｜Google Cloud（cloud.google.com/architecture）
- 参考資料：負荷テストのベスト プラクティス｜Cloud Run ドキュメント（cloud.google.com/run/docs）
- 参考資料：割り当てと上限の概要（Cloud Quotas）｜Google Cloud（cloud.google.com/docs/quotas）
Apigeeはサポートチケットの提出が必要
GCPのなかでも例外的に、個別の手続きが求められるサービスがあります。API管理プラットフォームのApigeeでは、ストレステスト・負荷テスト・ペネトレーションテストを実施する前に、サポートチケットの提出が求められます。自社のシステムがApigeeを使っている場合は、テスト計画にこの手続きを組み込んでおきます。
出典・参考資料（1件）
- 出典：ストレステスト、負荷テスト、ペネトレーション テストのリクエスト｜Apigee ドキュメント（cloud.google.com/apigee/docs）
GCP特有の確認対象（クラウドは設定ミスが狙われやすい）
オンプレミスのサーバーやWebアプリ単体を対象にしたテストと、クラウドのテストでは、見るべきポイントが大きく異なります。クラウドでは、ソフトウェアの脆弱性そのものよりも、権限設定やリソースの公開設定といった「設定ミス」が侵入の入り口になりやすいためです。ここからは、GCPでペネトレーションテストを行うときに特に確認したい対象を、大きく3つの領域に分けて整理します。
IAMの階層型権限とサービスアカウントキー
GCPのアクセス管理（IAM：Identity and Access Management）は、組織（Organization）・フォルダ（Folder）・プロジェクト（Project）という階層で構成され、上位で付与した権限は下位のリソースへ継承されます。この仕組みを理解せずに権限を付与すると、意図せず広い範囲に強い権限が行き渡ってしまうことがあります。
テストでは、必要以上の権限が付与されていないか、権限昇格につながる経路がないかを確認していきます。特に注意したいのが、プログラムからGCPを操作するためのサービスアカウントのキーです。キーがソースコードやリポジトリに残ったまま流出すると、攻撃者がそのサービスアカウントの権限でリソースを操作できてしまうため、キーの管理状況は重点的に確認する対象になります。
出典・参考資料（1件）
- 参考資料：IAM の概要（リソース階層とポリシーの継承）｜Google Cloud（cloud.google.com/iam/docs）
GKE・Cloud RunのRBACとコンテナ周りの設定
コンテナでアプリケーションを動かしている場合は、Google Kubernetes Engine（GKE）やCloud Run特有の設定も確認対象になります。GKEでは、クラスター内の権限を管理するRBAC（ロールベースのアクセス制御）の設定に不備があると、あるコンテナ（Pod）から本来アクセスできないはずのリソースへ到達できてしまうことがあります。
あわせて、ワークロードがGCPのサービスへアクセスする際の認証を安全に扱う仕組みであるWorkload Identityの設定や、コンテナイメージに不要な権限・認証情報が含まれていないかも確認します。コンテナからクラウドの認証情報へ到達できる経路は、クラウドならではの侵入シナリオになりやすい部分です。
Cloud Runのようなマネージドなコンテナ実行環境でも、サービスに紐づくサービスアカウントの権限が広すぎないかは、同じ観点で確認したいポイントです。
出典・参考資料（2件）
- 参考資料：ロールベース アクセス制御（RBAC）｜Google Kubernetes Engine ドキュメント（cloud.google.com/kubernetes-engine/docs）
- 参考資料：Workload Identity Federation for GKE｜Google Cloud（cloud.google.com/kubernetes-engine/docs）
Cloud Storageの公開設定とBigQueryの共有設定
データを保存するサービスの公開・共有設定も、見落とされやすい確認対象です。Cloud Storageのバケットは、アクセス権にallUsers（インターネット上の誰でも）を付与すると、認証なしで誰でもアクセスできる公開状態になります。意図せず公開設定のまま運用されていないかは、必ず確認したいポイントです。
BigQueryでは、データセットのIAM共有設定で、特定のユーザーやグループに加えてallAuthenticatedUsers（Googleアカウントでログインした全ユーザー）への付与が行われていないかを確認しておきます。本来は社内の限られたメンバーだけが見るべきデータが、広い範囲に共有されていないか、という観点での点検が欠かせません。
出典・参考資料（2件）
- 参考資料：公開データへのアクセス（allUsers による一般公開）｜Cloud Storage ドキュメント（cloud.google.com/storage/docs）
- 参考資料：データセットへのアクセスの制御｜BigQuery ドキュメント（cloud.google.com/bigquery/docs）
自社で実施するか専門会社に依頼するか（進め方・ツール・費用相場）
GCPでのテストの進め方には、自社で実施する方法と、専門会社に依頼する方法があります。どちらが適しているかは、社内に診断のスキルを持つ人材がいるか、対象システムの重要度や求められる精度はどの程度か、によって変わります。ここでは両者の進め方と費用の目安を整理します。
自社で実施する場合の進め方とツール
自社で実施する場合は、まず対象範囲とスケジュール・免責事項を関係者で合意し、対象のIPアドレスやリソースを確定させます。その後、情報収集・脆弱性スキャン・侵入の試行・報告という流れで進めます。報告ではリスクの深刻度と優先度をつけ、改善までを見据えて整理します。
ツールとしては、ポートスキャンに使うNmap、Webアプリケーションの診断に使うBurp Suite、エクスプロイトの検証に使うMetasploitなどが広く利用されています。
GCPの構成に固有の設定ミスを継続的に洗い出したい場合は、クラウドの設定を自動で点検するCSPM（Cloud Security Posture Management）型のツールを使う方法もあります。GCPが公開している負荷テストのガイドなど、公式ドキュメントを参照しながら進めると、規約の範囲を外れずに実施しやすくなります。
CSPMの仕組みや、よく似た名前の他のツールとの違いは、別の記事で詳しく解説しています。
専門会社に依頼する場合の費用相場と期間
高度な攻撃シナリオの検証や、第三者による客観的な評価が必要な場合は、専門会社に依頼する方法が現実的です。費用はサービスや対象範囲によって幅がありますが、公開されている料金を見ると、Webアプリケーションを対象とした脆弱性診断はおおむね数十万円から、本格的なペネトレーションテストは100万円を超える水準が目安になります。
GCPが対象だからといって費用が特別に上乗せされるわけではなく、相場は一般的な脆弱性診断・ペネトレーションテストと同じ水準です。
たとえば、後述するCoWorkerのプランでは、ソースコードと動的診断を組み合わせたプランが50万円、上位プランが100万円という設定です。別の診断会社が公開している料金でも、脆弱性診断が120万円程度から、ペネトレーションテストが150万円程度からで、期間は最短5〜10営業日程度とされる例があります。各社の具体的な料金は、後述のサービス比較表でも確認できます。
対象システムの規模や診断の深さによって変動するため、正式な金額は各社への見積依頼で確認します（2026年11月時点の各社公開情報にもとづく目安）。
ペネトレーションテストの費用は、対象（Web・ネットワーク・クラウド）や規模で大きく変わります。対象別・規模別の料金の目安や、見積もりを取るときの確認ポイントまで含めて相場観をつかみたい場合は、次の記事が参考になります。
一括ダウンロードする
GCPのペネトレーションテスト・クラウド設定検査に対応するサービス
ここからは、GCP上のシステムの脆弱性診断やペネトレーションテスト、クラウド設定の継続的な点検に対応するサービスを紹介します。自動スキャンで設定ミスを継続的に洗い出すツール型のサービスと、専門家が手動で検証するサービスでは、適した場面が異なります。まずは一覧で特徴を比較してください。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス | GMOサイバーセキュリティ byイエラエ |
|---|---|---|---|
| 診断方式 | ツール型（自動スキャンSaaS） | AI自動解析＋専門家による確認 | 専門家の手動主体＋ツール型ASM |
| 診断できる主な範囲 | ソースコード・クラウド設定・コンテナ・Webアプリ（DAST） | ソースコード・Web/API・ペネトレーションテスト | Web・クラウド・ネットワーク・IoTなど13種（AI診断は別メニュー） |
| GCP設定の検査（CSPM・クラウド診断） | ●CSPMでAWS・Azure・GCPに対応 | ×クラウド設定診断は提供メニュー外 | ●クラウド診断でGCPに対応（手動主体） |
| 手動ペネトレーションテスト | △人手の診断はAndGoが別サービスで提供 | ●実践攻撃シミュレーション診断として提供 | ◎ホワイトハッカーによる手動主体が強み |
| 料金目安 | 月額5万円台〜 （年間契約・利用者10人まで、参考価格） | ソースコードAI診断15万円〜 Lite 50万円／Standard 100万円 | 手動診断は要見積もり ネットde診断ASMは月額4万円〜 |
| 無料トライアル | あり | 記載なし | 記載なし |
| 詳細情報 | 公式資料を見る | 公式資料を見る | サービス詳細を見る |
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面でまとめて検査できるオールインワンの脆弱性診断SaaSです。株式会社AndGoが日本での窓口となり提供しています。人が診断してレポートを納品する受託型ではなく、ツールによる自動スキャンを継続的に使う契約形態である点が特徴です。
GCPとの関係で注目したいのが、クラウドの設定ミスを点検するCSPM機能です。公式のCSPMページでは、対応するクラウドとしてAWS・Azureに加えてGoogle Cloudが挙げられており、GCPの構成を対象に設定の不備を継続的に検出できます。
ソースコード診断（SAST・SCA）や動的なWebアプリ診断（DAST）もカバーするため、開発から運用までの弱点を一つの画面で見渡したい開発チームに向いています。人手によるペネトレーションテストは、AndGoが別サービスとして案内しています。
料金は、日本窓口のAndGoの参考価格で月額5万円台から（年間契約・利用者10人までのBasicプランの場合）とされており、無料トライアルも用意されています。正式な金額は為替や契約条件で変わるため、AndGoへの確認が必要です（2026年11月時点）。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する脆弱性診断サービスは、自社開発AI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせている点が特徴です。診断メニューは、ソースコードを読み取るソースコードAI診断、稼働中のWeb・APIを対象とする動的診断、そして実際の攻撃を想定した実践攻撃シミュレーション診断（ペネトレーションテスト）の3つで構成されます。
GCP上で運用するWebアプリケーションやAPIの診断を、実額が見える形で依頼したい場合に検討しやすいサービスです。CoWorkerのプランでは、ソースコードAI診断が15万円、ソースコードと動的診断を組み合わせたLiteプランが50万円、再診断を含む上位のStandardプランが100万円という構成になっています。
報告書はプレスリリースによると最短3営業日で納品されるとされています。クラウド上にデータを出したくない場合に、自社環境内でAIを動かす構成を選べる点も、情報の取り扱いに制約がある企業には選択肢になります。
GCP上のシステムも、一度テストして終わりではなく、設定変更や新しい攻撃手法に合わせた継続的な点検が重要になります。診断をどの程度の頻度で行うべきかという点について、CoWorker株式会社の一ノ瀬氏は、攻撃側の変化を背景に次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
3. GMOサイバーセキュリティ byイエラエ（GMOサイバーセキュリティ byイエラエ株式会社）
GMOサイバーセキュリティ byイエラエは、国内のホワイトハッカーを多数擁し、手動を主体とした脆弱性診断・ペネトレーションテストを強みとするサイバーセキュリティ専門企業です。診断メニューは13種にわたり、そのなかにAWS・Azure・Google Cloudなどを対象とするクラウド診断が明示されています。GCP環境を、専門家の知見で深く検証してほしい場合に候補になります。
Webペネトレーションテストでは、擬似攻撃で情報資産へのリスクを可視化するシナリオ型と、ソースコードなども含めて広く問題点を洗い出す調査型の2方式が用意されています。
料金は診断したい画面数・API数・攻撃シナリオをもとに個別見積となるため、対象範囲を伝えたうえで問い合わせる形になります。あわせて、攻撃面を継続的に点検するASM（攻撃面管理）ツール「GMOサイバー攻撃ネットde診断」も提供しており、こちらは月額制で利用できます。
まとめ
GCPでのペネトレーションテストは、自社が管理するプロジェクトやリソースを対象とする限り、Googleへの事前申請や承認なしで実施できます。守るべきなのは、対象を自社のリソースに限り、他のGoogle Cloud利用者に影響を及ぼさないという原則です。
負荷をかける手法は影響範囲に注意し、Apigeeを使う場合はサポートチケットの提出、Google製品自体の脆弱性は報奨金プログラムへの報告、という例外的な手続きも押さえておきます。
クラウドでは、ソフトウェアの脆弱性以上に、IAMの権限設定・コンテナの権限・ストレージの公開設定といった「設定ミス」が狙われます。自社での実施に加えて、CSPMツールでの継続点検や、専門会社による深い検証を組み合わせることで、GCP環境のリスクを着実に洗い出せます。自社の状況に合った進め方を選び、まずは資料で各サービスの対応範囲を比較してみてください。
GCP向けに限らず、脆弱性診断サービスを診断方法・費用相場・選び方の観点で広く比較検討したい場合は、次のまとめ記事で全体像をつかめます。
一括ダウンロードする
よくある質問（FAQ）
Q. GCPのペネトレーションテストとは何ですか？
A. GCPのペネトレーションテストとは、Google Cloud上で自社が運用するシステムに疑似的な攻撃を行い、侵入につながる脆弱性や設定の不備を洗い出す検査です。オンプレミスのサーバーやWebアプリ単体の診断と違い、クラウドではIAMの権限設定やストレージの公開設定といった「設定ミス」が侵入の入り口になりやすいため、こうしたGCP特有の構成まで含めて点検する点に特徴があります。
Q. GCPのペネトレーションテストにGoogleへの事前連絡は本当に不要ですか？
A. GCPのペネトレーションテストは、自社が管理するプロジェクトやリソースを対象とする限り、Googleへの事前の連絡や承認なしで実施できます。
Google Cloudは公式のセキュリティFAQで、ペネトレーションテストにあたってGoogleへ連絡する必要はない旨を明記しています。ただし対象を自社のプロジェクトのみに限ること、Apigeeを使う場合はサポートチケットを提出することなど、守るべき条件や例外的な手続きはあります。
出典・参考資料（1件）
- 出典：クラウドのセキュリティに関するよくある質問｜Google Cloud ヘルプ（https://support.google.com/cloud/answer/6262505）
Q. GCPのペネトレーションテストは稼働中の本番環境でも実施できますか？
A. GCPのペネトレーションテストは、稼働中の本番環境でも実施できますが、サービスへの影響を抑える設計が前提になります。
本番環境では、テストによる負荷やデータの変更が実際の利用者に及ぶおそれがあるため、実施する時間帯を調整したり、影響範囲を限定したりといった配慮が必要です。可能であれば本番と同等の検証環境を用意して先に試す、重要度の高いシステムは専門会社と相談しながら進める、といった方法でリスクを抑えられます。
Q. GCPのペネトレーションテストはAWSやAzureのテストと何が違いますか？
A. GCPのペネトレーションテストは、確認すべきクラウド固有の対象が、GCPのサービス構成に合わせて変わる点がAWSやAzureのテストとの主な違いです。
基本的な進め方（範囲の定義→情報収集→スキャン→侵入試行→報告）は共通です。ただしGCPでは、IAMの階層型権限（組織・フォルダ・プロジェクト）やサービスアカウントキー、GKE・Cloud RunのRBAC、Cloud Storageの公開設定など、GCP独自の仕組みを対象にします。また事前連絡の要否など各社の規約も異なるため、対象とするクラウドごとに公式の規約を確認する必要があります。
Q. GCPのペネトレーションテストの費用はいくらくらいかかりますか？
A. GCPのペネトレーションテストの費用は、対象範囲によって幅がありますが、Webアプリの脆弱性診断でおおむね数十万円から、本格的なペネトレーションテストで100万円を超える水準が目安です。公開料金の例では、ソースコードと動的診断を組み合わせたプランが50万円程度、上位プランが100万円程度、ペネトレーションテストは150万円程度からという設定も見られます。
一方、クラウド設定を継続的に点検するCSPM型のツールは月額数万円から利用できるものもあり、目的に応じて使い分けられます。正式な金額は対象システムの規模で変わるため、各社への見積依頼で確認してください（2026年11月時点の各社公開情報にもとづく目安）。
Q. GCPのペネトレーションテストは自社だけで実施すれば十分ですか？
A. GCPのペネトレーションテストを自社だけで行うか専門会社に依頼するかは、社内に診断スキルを持つ人材がいるか、対象システムの重要度や求められる精度がどの程度か、によって変わります。
設定ミスの継続的な洗い出しは、NmapやBurp SuiteなどのツールやCSPM型のツールを使えば自社でも進められます。一方、高度な攻撃シナリオの検証や、取引先・監査に示す第三者の客観的な評価が必要な場合は、専門会社に依頼する方が適しています。日常はツールで点検し、重要な場面で専門会社の診断を受けるという組み合わせも現実的です。
Q. GCPのペネトレーションテストでBigQueryやCloud SQLなどのデータサービスも診断対象にできますか？
A. GCPのペネトレーションテストでは、BigQueryやCloud SQL、Cloud Storage、GKEといったGCP上の各サービスも、自社が管理するリソースである限り診断対象にできます。
特にデータを扱うサービスでは、Cloud Storageのバケットが誰でもアクセスできる公開状態になっていないか、BigQueryのデータセットが意図せず広い範囲に共有されていないかといった設定面の点検が重要になります。対象にできる範囲は依頼先のサービスによって異なるため、診断を外注する場合は対応するGCPサービスを事前に確認してください。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、GCPをはじめとするクラウド環境に対応した脆弱性診断・ペネトレーションテストサービスの最新資料を無料で一括請求できます。診断範囲・料金・対応クラウドをまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
