Google WorkspaceのSOC 2コンプライアンス:知っておくべきこと

組織がSOC 2の取得を目指しているなら——そして、多くのB2Bソフトウェア企業は顧客から求められて最終的にそうすることになりますが——Google Workspaceはその対象範囲に含まれます。Google Workspaceには、監査人が検証する基準に直接対応するID情報、ドキュメント、アクセス制御が存在するためです。この記事では、Google WorkspaceがSOC 2プログラムにどのように関わるか、そして土壇場で慌てることなくWorkspace側の準備を進める方法について解説します。

最初に言葉の使い方について触れておきます。SOC 2は独立したCPA法人が実施する*アテステーション(証明業務)*であり、自ら授与するバッジではありません。その成果物は監査人によるレポートであり、自己申告のラベルではありません。社内で行えることは、アテステーションが円滑に進むよう、コントロールを構築・実証し、証跡を収集することです。本記事はまさにその点について取り上げます。

SOC 2の概要

SOC 2は、サービス組織のコントロールを信頼性サービス基準(Trust Services Criteria、TSC)に照らして評価します。基準には、セキュリティ(常に含まれ、しばしば「共通基準」と呼ばれます)のほか、任意で可用性、処理のインテグリティ、機密保持、プライバシーがあります。セキュリティ基準——CCシリーズ——において、Google Workspaceが最も多く登場します。

タイプIレポートは、ある時点においてコントロールが適切に*設計*されているかを評価します。タイプIIレポートは、一定期間(通常3~12か月)にわたってコントロールが*有効に運用*されていたかを評価します。顧客が通常求めるのはタイプIIであり、これには重要な意味があります。つまり、機能するコントロールと、その期間全体を通じて機能していたことを示す証跡が必要だということです——監査当日だけではありません。

Google Workspaceが基準にどう対応するか

いくつかの共通基準は、すでに皆さんが触れているWorkspaceのコントロールに明確に対応しています。

• CC6.1 — 論理アクセス制御。 保護された情報に誰がアクセスできるか、そしてアクセスがどのように認可されたユーザーに制限されているか。Workspaceの用語で言えば、アカウントのプロビジョニング、MFAの強制、共有制御、そして外部アカウントやサービスアカウントを含むすべてのIDが保持するアクセス権を指します。
• CC6.2 — 登録と認可。 新規ユーザーはアクセスが付与される前に登録・認可され、不要になった時点でアクセスが削除されます。ジョイナー・ムーバー・リーバー(入社・異動・退職時)の管理はここに含まれます。
• CC6.3 — 最小権限と職務分掌。 アクセスは役割に基づき、必要最小限に保たれます。過剰な権限付与や管理者権限の乱立は、この基準に対する指摘事項となります。
• CC6.6 — 外部脅威からの保護。 外部からアクセス可能な領域——公開リンク、外部共有、組織外のIDに付与されたアクセス——を指します。
• CC7.x — モニタリングとインシデント対応。 異常の検知とセキュリティイベントへの対応。共有やアクセスの変更を把握し、調査できる状態にあることが、これらの基準を支えます。

番号を暗記する必要はありません。重要なのは、MFAの強制、共有の制御、古くなったアクセス権の削除、サードパーティアプリのガバナンスといった日常的なWorkspace業務そのものが、監査人が確認したいコントロールの証跡である、という点です。

監査人が実際に求めるもの

監査人が求めるのは保証ではなく、証跡です。Workspace関連のコントロールについては、次のような要求を想定してください。

• MFAが強制されていることの証明(「有効にしました」という説明だけでなく、ポリシーとその適用状況)。
• 管理者のリストと、各特権ロールの根拠。
• アクセスレビューの証跡——機密データにアクセスできる対象者を定期的に確認し、判明した内容に対応していること。
• 従業員退職時のデプロビジョニング記録。
• 共有設定の内容と、外部共有がどのように制御されているか。
• セキュリティ上の指摘事項が解決に至るまで、どのように追跡されているかの記録。

繰り返し現れるテーマは、文書化され、再現可能なプロセスと、それを裏付ける監査証跡です。存在してはいても痕跡を残さないコントロールは、証明しづらいものです。継続的に運用され、発見内容を記録するコントロールは、証明しやすいものです。

Workspace側の準備方法

1. 構成のベースラインを確立する。 管理設定——共有、2段階認証プロセス、Marketplaceの制限、メール認証——の意図した状態を文書化し、定期的に実態と照合します。設定のずれ(ドリフト)は、クリーンな監査の敵です。
2. 証跡を残せるアクセスレビューを実施する。 外部IDや非人間ID(サービスアカウントなど)を含め、機密データにアクセスできる対象を定期的にレビューし、その結果を保存します。「四半期ごとにアクセスをレビューしました、これが記録です」と言えることこそ、CC6.3が求めているものです。
3. 共有設定を厳格化し、文書化する。 公開共有・外部共有を制御し、現在の状態を提示できるようにすることで、CC6.1とCC6.6に対応します。
4. 指摘事項を解決まで追跡する。 露出を発見したら、記録し、修正し、その経緯を保存します。これはモニタリングと是正措置の基準を支えます。
5. 監査ログを保持する。 セキュリティに関連する操作のタイムスタンプ付き記録があれば、「誰が、何を、いつ行ったか」という問いに容易に答えられます。

これらの多くは、一般的なGoogle Workspaceのセキュリティの実践と重なります——それがまさにポイントです。SOC 2は後付けの別プロジェクトではなく、皆さんのセキュリティ実践そのものを、可視化し証跡付きにしたものなのです。

継続的な証跡は、監査前の慌ただしさに勝る

典型的な失敗パターンは、コンプライアンスをイベントとして扱うことです。監査前の1か月間、スクリーンショットやスプレッドシートに追われる慌ただしい作業を毎年繰り返す、というものです。これはストレスが多く、ミスも起こりやすく、しかもタイプII監査人が当然疑問視するような、ある一時点だけの証跡しか生み出しません。

代替となるのは継続的な運用です。年間を通じて態勢を管理し、証跡を副産物として生成し、すでに整った証跡一式を持って監査に臨むというやり方です。指摘事項をSOC 2の基準にマッピングし、監査人にそのまま提出できる証跡を生成するポスチャーツールがあれば、慌ただしい作業がエクスポート一つで済むようになります。

監査のWorkspace部分でよくある落とし穴

いくつかのミスが繰り返し見られ、事前に対処しておく価値があります。

• 「設定済み」と「強制済み」を混同すること。 2段階認証プロセスのポリシーを有効にすることと、それがすべてのアカウントに適用されていることは別物です。監査人は後者を検証します。組織全体で強制が維持されているか確認してください——詳しくはGoogle Workspace全体でMFAを強制するガイドをご覧ください。
• アクセスレビューをチェックボックス扱いすること。 記録も、対象範囲も、フォローアップもない「アクセスをレビューしています」は証跡になりません。結果を保存し、指摘事項に対応した経緯を示してください。
• 非人間IDを見落とすこと。 サービスアカウントやAIエージェントもアクセス権を保持しています。最小権限(CC6.3)を検証する監査人は、「人間だけをレビューしました」では納得しません。これらもガバナンスの対象としてください——詳しくはリスクのあるAIエージェントの検知をご覧ください。
• 監査と監査の間に構成のずれを放置すること。 1月時点ではクリーンだったベースラインが6月にはずれてしまっている、というのはタイプIIの指摘事項につながります。年1回のスナップショットではなく、継続的なチェックこそが基準を維持します。

コンプライアンスは優れたセキュリティの副産物である

SOC 2のWorkspace側について最も有用な捉え直しは、皆さんは*監査のために*コントロールを構築しているのではなく、健全なセキュリティプログラムを運用し、その監査にそれを観察させているに過ぎない、という視点です。アクセス制御基準の下で監査人が確認したいことはすべて、監査の有無にかかわらず皆さんが望むはずのもの——強制されたID管理、制御された共有、ガバナンスの効いたサードパーティアクセス、維持された構成ベースライン——です。監査は、それを可視化し証跡付きにするよう求めているに過ぎません。

この考え方を身につけたチームは、年次サイクルを恐れなくなります。コントロールは一年を通じて稼働し、証跡は副産物として蓄積され、監査はそれ自体が独立したプロジェクトになるのではなく、すでに完了した業務のレビューになります。それこそが、実務上、慌てることと備えができていることの違いなのです。

8200.devは、皆さんのGoogle WorkspaceのポスチャーをSOC 2、ISO 27001、GDPRのコントロールファミリーにマッピングし、監査人に提出できる証跡パッケージを生成します——誠実に、実際に観測した範囲に限定し、根拠のないコンプライアンス主張は一切行いません。詳しくは仕組みや、私たち自身のセキュリティへの取り組みをご覧ください。

監査の準備を進めていますか? 無料のセキュリティ監査を開始すると、皆さんのGoogle Workspaceのポスチャーが、監査人が検証するアクセス制御基準にどう対応しているかを確認できます。