社内のメール・ファイル共有・スケジュール管理をGoogle Workspace（旧 G Suite）に集約している企業は少なくありません。全社の情報がクラウドの向こうにある状態になると、「攻撃されると困る穴が、自社の設定のどこかに空いていないか」を確かめたくなります。セキュリティ監査やISMSの更新で「ペネトレーションテスト（侵入テスト）を実施したか」と問われ、調べ始めた担当者も少なくありません。
ところが、いざ「Google Workspace ペネトレーションテスト」と検索しても、出てくるのはGoogle Cloud（GCP）を対象にした解説や脆弱性診断との一般的な違いが多く、GCPの話とWorkspaceの話が入り混じって、肝心の「自社のWorkspace環境を、どう・どこまで検査すればよいのか」の対象範囲がつかみにくく感じられます。
Workspaceはクラウド事業者が運用するSaaSのため、そもそも何をテストの対象にできるのかが分かりにくいのが実情です。
この記事では、Google Workspaceをペネトレーションテストの対象にできるのかという結論からお伝えします。続けて、検査する設定の一覧、事前申請の要否、脆弱性診断との違い、自己点検と委託の線引き、依頼先と費用の目安までを順に扱います。自社の点検として何から着手し、どこから先をプロに任せるべきかの判断材料としてご活用ください。
目次
一括ダウンロードする
Google Workspace（旧 G Suite）はペネトレーションテストの対象にできる？
結論から言うと、Google Workspaceそのもの（Gmailやドライブを動かしているGoogleのサーバー・基盤）に対して、自社が侵入テストを仕掛けることはできませんし、その必要もありません。Workspaceはクラウド事業者（Google）が運用するSaaSで、インフラやアプリケーションの安全はGoogle側が受け持つためです。
一方で、自社がテストや点検の対象にできる——そしてすべきなのは、自社テナントの側で管理している設定・利用者アカウント・共有範囲・外部アプリとの連携です。攻撃者に突かれる「穴」の多くは、この利用者側の設定に生じます。
この役割分担は、Googleが「共有責任モデル」として公式に示しています。クラウドのデータ保護は事業者と利用者の協業で、SaaSでは物理・仮想インフラとプラットフォーム層をGoogleが管理します。利用者が受け持つのは「自社がWorkspaceに置くコンテンツと、そのアクセスポリシー（利用者やデータへのアクセス制御）」の安全です。
Google Workspace is software as a service (SaaS) where almost everything except the content and its access policy is the responsibility of the CSPs.
出典：Google Workspace data protection implementation guide（December 2020）｜Google
「Google Workspaceのペネトレーションテスト」で本当に確かめたいのは、Googleの堅牢性ではなく、自社テナントの設定・運用に生まれた弱点です。以降では、その検査対象を具体的に一覧化し、どこまでを自分で確認し、どこから先を専門会社のペネトレーションテストに委ねるかを、監査やISMS更新で第三者の検証が求められる場合も含めて整理します。
Google Workspaceのペネトレーションテストで検査する対象
ここからは、自社テナントで優先して点検すべき設定を、管理者が管理コンソールを入口から順にたどる形で挙げます。まず下の一覧で全体像と「どこを・どう見ればよいか」をつかみ、各項目の詳しい見方は続くセクションで補足します。いずれもGoogle Workspace管理者ヘルプに対応する機能ページがあり、設定の所在まで確認できます。
| 点検する対象 | 管理者権限・全体ポリシー | 2段階認証（2SV） | 旧式認証（安全性の低いアプリ） | ドライブの外部共有 | OAuth連携アプリの権限 | 退職者・休眠アカウント | 検知・監視・条件付きアクセス |
|---|---|---|---|---|---|---|---|
| 確認する場所（管理コンソール） | アカウント＞管理者ロール／セキュリティ | セキュリティ＞認証＞2段階認証プロセス | セキュリティ＞アクセスとデータ管理 | アプリ＞Google Workspace＞ドライブとドキュメント＞共有設定 | セキュリティ＞API の制御＞アプリのアクセス制御 | ディレクトリ＞ユーザー | セキュリティ＞アラートセンター／DLP／コンテキストアウェアアクセス |
| 見るポイント・望ましい状態 | 特権管理者は必要最小限（復旧用に複数名は確保）、退職・異動者の権限は残さない、全管理者に2段階認証 | 「任意」ではなく組織全体で「強制（enforcement）」、新規ユーザーにも自動適用 | 組織全体で無効が基本。業務上必要な場合のみ最小範囲で許可 | 「リンクを知る全員が閲覧可」の社外秘を作らない、共有先は許可ドメイン限定が基本 | メール・ドライブ等の高リスクスコープを持つ不要アプリを棚卸し・ブロック | 退職者は速やかに停止・削除、共有権限・連携アプリも解除、長期未ログインを洗い出し | アラートが管理者に届く、機密情報の社外送信を検知、アクセス条件を必要な範囲に（DLP・条件付きは上位エディション） |
※管理コンソールのメニュー名・階層は、エディションや時期により異なる場合があります。これらの状態は「セキュリティ健全性ページ」「セキュリティ ダッシュボード」でまとめて確認できます（後述）。
Googleも中〜大規模組織（100ユーザー以上）向けに、上記とおおむね同じ項目を並べたセキュリティチェックリストを公開しています。
管理コンソールの管理者権限と全体のセキュリティポリシー
最初に見るのは、管理コンソール（admin.google.com）にアクセスできる管理者アカウントそのものです。特権管理者の数が必要以上に多くないか、退職・異動した人の管理者権限が残っていないか、各管理者アカウントに2段階認証がかかっているかを確認します。管理者アカウントを1つ奪われると、組織全体の設定を書き換えられてしまうため、ここが最大の起点になります。
あわせて、パスワードの強度ポリシーやセッションの有効期限など、組織全体に効くセキュリティポリシーの既定値も点検します。
2段階認証（2SV）が全員に強制されているか
パスワードの漏えいや使い回しによる乗っ取りを防ぐ最も効果の高い設定が、2段階認証（2-Step Verification、2SV）の強制です。「任意で推奨」にとどめると、設定していない利用者が必ず残ります。管理者は組織部門やグループ単位で2SVを必須にし、適用開始日を指定して全員に行き渡らせることができます。
点検では、2SVが有効化されているだけでなく「強制（enforcement）」になっているか、新しく入った利用者にも自動で適用されるかを確認します。設定場所と手順はGoogle Workspace管理者ヘルプに記載があります。
旧式認証（安全性の低いアプリ）が2段階認証を迂回していないか
2段階認証を強制していても、古い方式でログインするアプリが許可されたままだと、その抜け穴から認証を迂回されることがあります。Googleはこうしたアプリを「安全性の低いアプリ（less secure apps）」と呼び、最新の認証標準を使わないぶんリスクが高いと説明しています。
Less secure apps don’t use modern security standards, such as OAuth, and increase the risk of accounts or devices being compromised.
出典：Control access to less secure apps｜Google Workspace 管理者ヘルプ
点検のポイントは、安全性の低いアプリのアクセスが組織全体で無効になっているかどうかです。Googleは2025年5月以降、旧式のユーザー名・パスワード認証に依存するアプリのサポートを順次終了してOAuthを必須化しており、Google側でも既定の無効化が進んでいます。業務アプリが古い認証に依存している場合は、OAuthなどの新しい方式へ移行できないかもあわせて検討するとよいでしょう。
ドライブ・共有ドライブの外部共有設定
情報漏えいの入口として見落とされやすいのが、Googleドライブの外部共有です。「リンクを知っている全員が閲覧可」のまま社外秘のファイルが共有されていないか、組織外のドメインへの共有がどこまで許可されているか、共有ドライブ単位の権限が適切かを点検します。
管理者は、組織全体やドライブ単位で外部共有のポリシーを設定・制限でき、どのファイルが外部に共有されているかを調査することも可能です。点検の勘所は「許可が広すぎないか」と「意図せぬ公開共有が放置されていないか」の2点です。
OAuth連携サードパーティアプリの権限
利用者が過去に「Googleでログイン」で許可した外部アプリは、メールやドライブのデータにアクセスできる権限を持ち続けていることがあります。退職者が使っていたツールや、一度試しただけのサービスが、気づかないうちにデータへの通り道として残るのがリスクです。
管理者は、どのサードパーティアプリ・内部アプリがWorkspaceのデータにアクセスできるかを一覧で確認し、メールやドライブへのアクセスといった「高リスクなOAuthスコープ」を持つアプリを制限・ブロックできます。点検では、不要なアプリの連携を棚卸しし、必要なものだけを許可リストに残します。
退職者・休眠アカウントの放置
退職した従業員のアカウントが停止されないまま残っていると、それ自体が侵入経路になります。本人が外部から使い続けられる状態や、共有ファイル・連携アプリへのアクセスが生きたままの状態は、攻撃者にとって監視の目が届きにくい格好の標的です。長期間ログインのない休眠アカウントも同様です。
点検では、利用者一覧から現職者と突き合わせ、退職者アカウントが速やかに停止・削除され、保有していた共有権限や連携アプリの権限が引き継ぎ・解除されているかを確認します。この「放置アカウント」はセキュリティ製品では気づきにくく、運用ルールと定期的な棚卸しで塞ぐ領域です。
アラートセンター・DLP・コンテキストアウェアアクセス（検知・監視・条件付きアクセス）
設定の穴を塞ぐだけでなく、不審な動きを検知し、アクセスできる条件を絞る仕組みも点検対象です。アラートセンターは、不審なログインやデータ流出の兆候といったセキュリティ通知を一元的に受け取る機能で、通知が適切に管理者へ届く設定になっているかを確認します。
DLP（データ損失防止）は、クレジットカード番号などの機密情報が社外へ共有・送信されるのをルールで検知・ブロックする仕組みです。コンテキストアウェアアクセスは、利用者の所在地・デバイスの状態などの条件に応じてアクセスの可否を変える機能で、社外からの不正アクセスの範囲を狭めます。
ただし、DLPとコンテキストアウェアアクセスはEnterprise Standard・Enterprise Plusなどの上位エディションで提供される機能（Business Plusでは利用できません）です。自社の契約プランで利用できるかをあわせて確認しておくとよいでしょう。
出典・参考資料（3件）
一括ダウンロードする
Googleへの事前申請（許可取り）は必要？
「勝手にテストしてGoogleの規約に触れないか」「アカウントを止められないか」という不安は、よく聞きます。前提として、ここまで挙げた自社テナントの設定・共有・権限・アカウントの点検は、管理コンソールで自社の設定を確認・変更する作業であり、Googleのサービスを攻撃する行為ではありません。したがって、点検そのものにGoogleへの事前申請は不要です。
自社が管理するクラウドやネットワーク（たとえばGoogle Cloud上の自社プロジェクトや、自社で運用するサーバー）に対して委託のペネトレーションテストを行う場合も、Googleは「自分のプロジェクトを対象にするペネトレーションテストにGoogleへの連絡は不要」と案内しています。
ただし条件があり、テストは自分のリソースだけに影響させ、他の利用者の環境に及ぼしてはなりません。もしテストの過程でGoogleの製品・基盤側の脆弱性に気づいた場合は、Googleの脆弱性報奨金制度（VRP）へ報告することが求められています（自社の設定不備を報告する義務ではありません）。
一方で、やってはいけないことも規約で明確に決まっています。Googleの利用規定（Acceptable Use Policy）が禁止しているのは、サービスやその提供設備への不正アクセス・妨害、サービスの利用を妨げる行為（DoS的な手法）です。加えて、Googleのサービスそのものを脆弱性や制限を見つける目的でテストすること（契約で明示的に許可された場合を除く）も禁止されています。
出典：Acceptable Use Policy｜Google Cloud（Google Workspace向け条項を含む）
- to gain unauthorized access to, disrupt, or impair the use of the Services, or the equipment used to provide the Services, by customers, authorized resellers, or other authorized users;
- to test or reverse-engineer the Services in order to find limitations or vulnerabilities, or to evade filtering capabilities, except as expressly permitted in the Agreement;
まとめると、点検・テストしてよいのは「自社が提供・管理している部分」であり、Googleの基盤・他テナント・Workspaceというサービス本体そのものを攻撃対象にはできません。
この線引きを守る限り、自社テナントの点検や、自社リソースを対象にした委託ペネトレーションテストにGoogleへの事前申請は不要です。委託する場合は、対象範囲が自社の管理下にあることを委託先と事前にすり合わせておくと安心です。
脆弱性診断とペネトレーションテストの違い（Workspaceにはどちらが要る？）
「ペネトレーションテスト」と「脆弱性診断」は混同されがちですが、目的とやり方が異なります。脆弱性診断は、既知の弱点パターンに沿ってシステム全体を網羅的にチェックし、弱点を洗い出す検査です。ペネトレーションテストは、専門家が実際の攻撃者のように複数の弱点を組み合わせて侵入を試み、「どこまで侵入できるか」を検証します。両者の違いと一般的な相場を整理すると、次のようになります。
| 検査の種類 | 脆弱性診断 | ペネトレーションテスト |
|---|---|---|
| 目的 | 既知の弱点を網羅的に洗い出す | 実際に侵入できるか、被害がどこまで及ぶかを検証する |
| やり方 | ツール中心に、弱点パターンを体系的にチェック | 専門家が複数の弱点を組み合わせ、攻撃者の視点で侵入を試みる |
| 向く場面 | 定期的な棚卸し、予算や着手の最初の一歩 | 重要システムで「本当に守れるか」を確かめたいとき |
| 費用相場の目安 | 数十万〜200万円程度 | 200万円〜数百万円以上 |
| 期間の目安 | 2〜4週間程度 | 数週間〜数か月 |
※費用・期間は一般的な相場の目安です。対象範囲・検証の深さによって変動します。
Google Workspaceの文脈では、まず自社でできるのは「設定の棚卸し」に近い作業で、これは脆弱性診断よりさらに手前の自己点検にあたります。
その上で、Workspaceと連携する自社のWebアプリケーションやクラウド基盤まで含めて「実際に突破されないか」を確かめたい場合に、脆弱性診断やペネトレーションテストを専門会社へ委託するのが現実的な進め方です。重要システムを抱える企業や、監査で第三者の検証を求められる企業ほど、ペネトレーションテストの必要性が高くなります。
自社にどちらが必要かを、目的・費用・選び方の観点からさらに踏み込んで判断したい場合は、両者の違いを比較した以下の記事が参考になります。
ペネトレーションテストと脆弱性診断の違いを比較｜目的・費用・選び方まで解説
セキュリティ診断の導入を検討し始めると、「ペネトレーションテスト」と「脆弱性診断」という似た言葉に出会い、どちらを頼めばよいのか迷う場面が少なくありません。名前は違っても目的が近そうに見えるため、社内や取引先に説明するときも整理に困りがちで…
自分で確認できる範囲とプロに委託すべき範囲の線引き
Workspaceのセキュリティ点検は、すべてを外部に頼む必要はありません。自社の管理者でも確認できる範囲と、専門会社に委ねたほうがよい範囲を切り分けると、予算と手間を抑えられます。
自分で確認できるのは、前章で挙げた管理コンソールの設定群です。Google Workspaceには、管理者が自社の設定状態を一覧で点検できる「セキュリティ健全性ページ」や「セキュリティ ダッシュボード」が用意されており、2段階認証の適用状況や外部共有の設定などを俯瞰して、推奨設定とのギャップを確認できます。まずはここで自社の現状を把握するのが出発点です。
出典・参考資料（1件）
個人のGoogleアカウント向けには「セキュリティ診断（Security Checkup）」という点検機能もありますが、これは個人アカウントのログイン履歴や連携アプリを本人が確認するための補助機能です。組織全体のテナントを管理者の立場で点検する場合は、上記のセキュリティ健全性ページ・ダッシュボードを使います。
一方、専門会社に委託すべきなのは、設定の確認だけでは分からない「実際に突破できるか」の検証です。Workspaceと連携する自社開発のWebアプリケーション、Google Cloudなどのクラウド基盤、社内ネットワークまで含めて攻撃者の視点で侵入可否を確かめる作業は、専門の技術と第三者の客観性が要ります。
監査やISMS更新で第三者による検証の証跡を求められる場合も、委託が前提になります。次章で、依頼できるサービスと費用の目安を整理します。
Google Workspaceのセキュリティ点検を依頼できるサービスと費用の目安
その前に、委託が必要になるのはどんな企業かをはっきりさせておきます。Workspaceのテナント設定そのものの点検は、前章の自己点検（セキュリティ健全性ページでの確認）と運用ルールで完結できます。
委託が効いてくるのは、Workspaceと連携する自社開発のWebアプリケーションや、Google Cloud・AWSなどのクラウド基盤を併せて持っている場合です。そこが実際の侵入口になりうるため、第三者の検査対象になります。連携アプリや独自基盤を持たず、Workspaceテナントの設定だけが気になる段階なら、まずは自己点検と、脆弱性診断サービス全体を見渡せる関連記事で十分です。
委託の選択肢は、大きく2つの方向に分かれます。1つは、自社のWebアプリケーションやネットワークを対象に「実際に侵入できるか」を人の手で検証する、単発のペネトレーションテスト。もう1つは、クラウドの設定ミスを継続的に検査し続けるツール（CSPM）です。それぞれ役割と費用感が異なるため、まず下の比較で全体像をつかんでください。
| サービス名 | CoWorker 脆弱性診断サービス | Aikido Security |
|---|---|---|
| 提供形態 | 単発の委託ペネトレーションテスト （人が診断し報告書を納める受託型） | クラウド設定を継続検査するCSPM／SaaS （ツールで常時スキャンするサブスク型） |
| 検査できる範囲 | Webアプリケーション・API・ ソースコード・ネットワーク | クラウド設定（AWS・Azure・Google Cloud）・ ソースコード・依存ライブラリ・ コンテナ・稼働中のWebアプリ |
| 費用の目安 | Webアプリのペネトレーションテスト60万円〜／ ネットワーク100万円〜 （ソースコード診断は15万円〜） | 月額固定のサブスクリプション型 Basic 年額3,780ドル（月額5万円台〜）／ Pro 年額7,560ドル ※日本円で案内・無料トライアルあり |
| 料金体系 | 対象・範囲ごとの個別見積もり（都度） | 利用者（エンジニア）数に応じた年額（継続） |
| 向いているケース | 連携する自社のWebアプリや ネットワークを「実際に突破されないか」 確かめたいとき。監査・ISMS更新で 第三者検証の証跡を求められるとき | クラウド基盤の設定ミスを 継続的に点検し続けたいとき。 一度きりの診断で終わらせず 設定を放置しない運用に |
| 提供元 | CoWorker株式会社 | 株式会社AndGo （開発元はベルギーのAikido Security社） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
ここで取り上げたのは、Workspace連携環境の点検に向く2サービスに絞った例です。脆弱性診断サービスを診断方法・費用相場・選び方の観点で広く比較し、委託先を腰を据えて検討したい場合は、以下の記事もあわせてご覧ください。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
委託する場合の進め方（流れ）
委託のペネトレーションテストは、おおむね次の流れで進みます。まず、何を対象に・どこまで深く検証するか（範囲とシナリオ）を委託先とすり合わせます。このとき、対象が自社の管理下にあること、Googleのサービス本体を攻撃対象にしないことを確認しておきます。
次に、合意した範囲で専門家が侵入を試み、最後に「どこまで侵入できたか」「どの弱点をどう直すか」をまとめた報告書を受け取ります。報告会で結果の解説を受けられるサービスもあります。費用は対象範囲・シナリオ数・報告内容で変わるため、2〜3社から相見積もりを取り、範囲の定義が揃った状態で比べるのが失敗しないコツです。
クラウド設定を継続検査するCSPMという選択肢（一度きりで終わらせない）
ペネトレーションテストは、ある時点での侵入可否を確かめる「健康診断」です。しかし、クラウドの設定は日々変わり、新しい連携や権限が増えるたびに穴が生まれます。そこで、クラウドの設定ミスを継続的に検査し続けるCSPM（クラウドセキュリティ態勢管理）という仕組みが選択肢になります。これはツールで常時スキャンする方式で、設定が推奨から外れた箇所を自動で検知します。
Workspaceそのものの設定を直接見張る用途とは限りませんが、Workspaceと並行して使うGoogle Cloud・AWS・Azureなどのクラウド基盤の設定を放置しないための現実的な手段です。単発のペネトレーションテストと、継続検査のCSPMは、どちらか一方ではなく組み合わせて考えると過不足がありません。
CSPMがどんな仕組みで、CWPP・SSPM・CASB・CNAPPといった似た用語とどう違うのかを基礎から押さえたい場合は、以下の記事で詳しく解説しています。
CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた診断サービスです。診断メニューは、ソースコードを解析する静的診断、稼働中のWebアプリケーションやAPIを対象にした動的診断、そして実際の攻撃を想定して侵入可否を検証するペネトレーションテスト（実践攻撃シミュレーション診断）の3段階が用意されています。
料金は、ソースコード診断が15万円から、動的診断がAPIのエンドポイント数に応じて30万円から、Webアプリケーションのペネトレーションテストが60万円から、ネットワークのペネトレーションテストが100万円からと、対象ごとに段階的に選べます（金額は2026年11月時点の公表情報。実際の費用は対象規模で変わります）。
AIで解析の速度を上げることで、従来より短い期間での診断を掲げている点も特徴です。Workspaceと連携する自社のWebアプリケーションやネットワークまで「実際に突破されないか」を確かめたい場合の委託先として検討できます。
診断をいつ・どの頻度で行うべきかは、攻撃側の変化とも関わる論点です。この点について、同サービスを提供するCoWorker株式会社の一ノ瀬氏は、取材で次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
Aikido Security（株式会社AndGo）
ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリケーションを、1つの管理画面でまとめて継続的に検査するSaaSがAikido Securityです。クラウド設定の継続検査（CSPM）はAWS・Azure・Google Cloudなどに対応し、設定の不備を自動で検知します。
人が診断して報告書を納める受託型ではなく、ツールで常時スキャンする契約形態のため、「一度きりの診断で終わらせず、設定を放置しない」運用に向いています。開発元はベルギーのAikido Security社で、日本では株式会社AndGoが日本語での窓口・導入支援を担います。
料金はスポットの診断ごとではなく、月額固定のサブスクリプション型です。日本窓口のプランは、Basicが年額3,780ドル（月額5万円台から。年間契約・利用者10人までの参考価格）、上位のProが年額7,560ドルで、請求は為替を考慮した日本円での案内となります（金額は2026年11月時点の参考価格）。
無料で試せるトライアルも用意されています。クラウド基盤の設定点検を継続的に回したい企業に適した選択肢です。
単発の侵入テストと継続的な検査の関係は、今後さらに変わっていく可能性があります。AI時代のセキュリティの見通しについて、株式会社AndGoの原氏は取材で次のように語っています。
AIコーディングが当たり前になるほど、「AIが書いたコードも含めて、日常的に検証できる仕組み」が重要になります。その文脈で、AIエージェントがハッカーをエミュレーションして侵入テストを行い、ログや証跡を残す“AIペンテスト”の方向性も出てきています。これが進むと、コストや時間の都合で「リリース前に1回」が限界だった侵入テストを、ビルドパイプラインに組み込み、毎日回す世界が見えてきます。
まとめ
Google Workspaceの「ペネトレーションテスト」で確かめるべきは、Googleの基盤ではなく自社テナントの設定・共有・権限・アカウントです。まずは管理コンソールで、2段階認証の強制、旧式認証の無効化、外部共有の範囲、OAuth連携アプリの棚卸し、退職者アカウントの停止、検知・監視機能の設定を点検し、セキュリティ健全性ページで現状を把握します。
その上で、連携する自社のWebアプリケーションやクラウド基盤まで「実際に突破されないか」を確かめたい場合に、専門会社のペネトレーションテストや、設定を継続検査するCSPMを組み合わせて委託するのが、過不足のない進め方です。費用と対象の当たりをつけ、相見積もりに進む材料としてご活用ください。
一括ダウンロードする
よくある質問（FAQ）
Q. Google Workspaceのペネトレーションテストとは何ですか？
A. Googleが運用する基盤ではなく、自社テナント側で管理する設定・アカウント・共有範囲・外部アプリ連携に、攻撃者が侵入できる穴がないかを検証する点検を指します。WorkspaceはSaaSのため、Gmailやドライブを動かすGoogleのサーバーは利用者がテストする対象ではなく、その必要もありません。
実際に点検・テストできるのは、管理コンソールの設定や2段階認証の運用、外部共有の範囲など、自社の責任範囲に限られます。
Q. Google Workspaceのペネトレーションテストは、セキュリティ監査やISMS更新の「実施済み」の裏付けになりますか？
A. 専門会社に委託し、検証範囲と結果をまとめた報告書を受け取る形であれば、監査やISMS更新で求められる第三者検証の証跡になります。自社の管理者が管理コンソールの設定を点検するだけのセルフチェックは、現状把握には有効ですが、客観的な第三者の検証としては扱われないのが一般的です。
監査で「ペネトレーションテストを実施した」と示す必要がある場合は、対象範囲（自社のWebアプリケーションやクラウド基盤など）を定めたうえで、外部委託を前提に進めるのが確実です。
Q. Google Workspaceのペネトレーションテストでは、Gmailや連携しているSaaSも対象になりますか？
A. Gmailやカレンダーなどの個別サービスは、Workspaceテナントの設定の一部としては点検対象になりますが、Googleが運用するそれらの基盤そのものは対象外です。外部SaaSとの連携は、「OAuth連携アプリにどこまでの権限を与えているか」という形で点検します。
連携先のSaaSや自社開発アプリそのものの侵入テストが必要な場合は、そのサービス・アプリを対象に、別途ペネトレーションテストを設計します。
Q. Google Workspaceのセキュリティ点検を無料でできる方法はありますか？
A. 管理者向けの「セキュリティ健全性ページ」やセキュリティ ダッシュボードを使えば、追加費用なしで自社テナントの設定状況を点検できます。これらはWorkspaceの契約に含まれる標準機能で、2段階認証の適用状況や外部共有の設定を推奨値と見比べられます。個人アカウント向けには「セキュリティ診断（Security Checkup）」もあります。
ただし「実際に突破されるか」を人の手で検証する委託のペネトレーションテストは有料で、無料の自己点検とは役割が異なります。
出典・参考資料（1件）
Q. Google Workspaceのセキュリティ点検はどのくらいの頻度で行うべきですか？
A. 決まった頻度の定めはありませんが、少なくとも年1回の定期点検に加え、組織変更・退職者の発生・新しい外部アプリ連携の追加といった変化があった都度、確認するのが現実的です。クラウドの設定は日々変わり、新しい権限や共有が増えるたびに穴が生まれるため、単発の点検だけでは抜けが残ります。
設定の推奨値からのずれを常時検知したい場合は、クラウド設定を継続検査するCSPMを併用すると、点検の間隔が空く問題を補えます。
Q. Google Workspaceのペネトレーションテストは自社だけで完結できますか？
A. 管理コンソールの設定を棚卸しする自己点検は自社の管理者だけで完結できますが、「実際に侵入できるか」の検証までは専門会社への委託が現実的です。2段階認証の強制や外部共有の制限、OAuth連携アプリの棚卸しは、管理者がセキュリティ健全性ページを見ながら自力で進められます。
一方、Workspaceと連携する自社のWebアプリケーションやクラウド基盤まで含めて攻撃者の視点で侵入可否を確かめる作業は、専門の技術と第三者の客観性が要るため、外部に委ねるのが適切です。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、クラウドやWebアプリケーションの脆弱性診断・ペネトレーションテスト・継続検査サービスの最新資料を無料で一括請求できます。検査の対象範囲・料金・サポート体制を横並びで比べられます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
