このコンテンツは 2025 年 2 月に最終更新されたものであり、記載された時点での現状を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。
このドキュメントでは、Google の担当者がお客様のデータにアクセスできるようにする機能とプロダクトについて説明します。Google Cloud 利用規約で定義されているように、「顧客データ」とは、お客様またはエンドユーザーが自分のアカウントを使用して、サービス経由で Google に提供するデータです。
特権アクセスの概要
通常、お客様のデータにアクセスできるのは、お客様と、お客様が有効にした Google Cloudサービスのみです。契約サービス（サポートが必要な場合やサービス停止からの復旧が必要な場合など）を提供するために、Google の担当者がお客様のデータにアクセスする必要がある場合があります。このタイプのアクセスは、特権アクセスと呼ばれます。
一時的に昇格された権限を付与されたり、昇格された権限を取得したりした高権限の従業員は、内部リスクが高くなります。Google の権限アクセスへのアプローチは、考えられる攻撃ベクトルの数を減らすことを中心に行われています。たとえば、次のセキュリティ制御を使用します。
- 冗長な認証スキーム
- 限定的なデータアクセス パスウェイ
- システム全体のロギングとアラート アクション
- 規制対象の権限
このアプローチにより、内部攻撃を制御して検出し、インシデントの影響を制限し、データに対するリスクを軽減できます。
Google Cloud の特権アクセス管理戦略では、Google 社員が顧客データを表示または変更する能力が制限されています。Google Cloudでは、特権アクセスに対する制限がプロダクトの設計方法の不可欠な要素になっています。
Google の担当者がお客様のデータにアクセスする可能性がある場合の詳細については、Cloud のデータ処理に関する追加条項をご覧ください。
特権アクセスの基本方針
Google の特権アクセスの基本方針では、次のガイドライン原則が使用されます。
アクセス制限は、役割と複数の当事者の承認に基づく必要がある: Google の担当者は、デフォルトでシステムへのアクセスが拒否されます。アクセス権が付与されても、それは一時的なものであり、役割を実行するために必要な範囲を超えることは決してありません。顧客データへのアクセス、本番環境システムの重要なオペレーション、ソースコードの変更は、手動と自動の検証システムによって制御されます。Google の担当者は、別の担当者がリクエストを承認しない限り、お客様のデータにアクセスできません。担当者は、業務に必要なリソースにのみアクセスできます。また、お客様のデータにアクセスするには、正当な理由を提示する必要があります。詳細については、Google が本番環境のサービスを保護する方法をご覧ください。
ワークロードをエンドツーエンドで保護する必要がある: 転送中暗号化、保存中暗号化、使用中の暗号化のための Confidential Computing により、 Google Cloud はお客様のワークロードのエンドツーエンドの暗号化を提供できます。
ロギングと監査は継続的に行われます。Google 社員によるお客様データへのアクセスはログに記録され、脅威検出システムがリアルタイムで監査を行い、ログエントリが脅威インジケータと一致するとセキュリティ チームにアラートを送信します。内部セキュリティ チームは、アラートとログを評価して異常なアクティビティを特定し、調査して、インシデントの範囲と影響を制限します。インシデント対応の詳細については、データ インシデント対応プロセスをご覧ください。
アクセスは透過的で、お客様による制御が含まれている必要があります。顧客管理の暗号鍵（CMEK）を使用すると、独自の暗号鍵を管理し、それへのアクセスを制御できます。さらに、アクセスの透明性により、すべての特権アクセスにビジネス上の正当な理由が記録されます。Access Approval を使用すると、Google の担当者による特定のデータセットへのアクセス リクエストを承認または拒否できます。
Google 社員による顧客データへのアクセス
デフォルトでは、Google の担当者は Google Cloud お客様のデータにアクセスできません。
アクセス権を取得するには、Google の担当者が次の条件を満たしている必要があります。
- 関連するアクセス制御リスト（ACL）のメンバーである。
- Google のデータアクセス ポリシーを定期的に確認し、同意してください。
- 信頼できるデバイスを使用します。
- Titan セキュリティ キーを使用して多要素認証でログインすると、認証情報がフィッシングされるリスクを最小限に抑えることができます。
- 提供された理由（サポート チケットや問題 ID など）、ユーザーの役割、コンテキストを評価するツールにアクセスします。
- ツールで必要な場合は、別の適格な Google 担当者から承認を得ます。
- Access Approval に登録している場合は、承認を得ます。
人員の役割によって必要なアクセスレベルは異なります。たとえば、サポートロールには、カスタマー サポート チケットに直接関連する顧客データへのアクセスが制限されています。エンジニアリング ロールでは、サービス信頼性やサービスのデプロイに関連する複雑な問題に対処するために、追加のシステム権限が必要になる場合があります。
Google が Google サービスを提供するために第三者（カスタマー サポート ベンダーなど）と協力する場合は、その第三者が適切なレベルのセキュリティとプライバシー対策を講じているかどうかを確認しています。 Google Cloud は、サービスの提供に使用されるすべてのサブプロセッサのリストを公開しています。
Google の担当者がお客様のデータにアクセスする理由
Google Cloud は、Google 社員による顧客データへのアクセスを自動化、最小限に抑える、または排除するように設計されていますが、Google 社員が顧客データにアクセスする必要がある場合もあります。このようなケースには、お客様が開始したサポート、サービス停止やツールの障害、サードパーティの法的リクエスト、Google が開始した審査などがあります。
お客様からのサポート要請
アクセスの透明性を使用するサービスで Google の担当者がお客様のデータにアクセスするのは、通常、カスタマーケアへの連絡など、お客様が開始したイベントの結果です。問題の解決のためにカスタマーケア担当者に連絡した場合、カスタマーケア担当者は機密性の高いデータにアクセスすることはできません。たとえば、バケットへのアクセス権を失った場合、カスタマーケア担当者はバケット名などの機密性の高いデータにアクセスできません。
サービス停止またはツールの障害
サービス停止中やツールの障害発生中、Google の担当者は必要に応じてお客様のデータにアクセスしてバックアップや復元を行うことができます。このような場合、Google の担当者はお客様のデータに直接アクセスできるツールを使用して、効率を最大限に高め、問題を迅速に解決します。これらのツールは、このアクセスとエンジニアが提供した理由を記録します。また、アクセスは Google セキュリティ対応チームによって監査され、ログに記録されます。サポートされている Google Cloudサービスは、停止中に表示されるアクセスの透明性ログを生成します。停止中、エンジニアはリソースの許可リストをバイパスすることはできませんが、管理者の承認なしにデータにアクセスできます。
サードパーティからの法的要請
サードパーティからの法的リクエストはまれであり、有効な法的アクセスの正当化を生成できるのは法務チームのみです。法務チームがリクエストを確認し、リクエストが法的要件と Google のポリシーを満たしていることを確認します。また、法的に許可されている場合はお客様に通知し、法律で認められる範囲でデータ開示に対する異議申し立てを検討します。詳細については、お客様のクラウドデータに関する政府からの要請（PDF）をご覧ください。
Google が審査を開始
Google がレビューを開始することもまれです。問題が発生した場合は、お客様のデータが安全に保護され、侵害されていないことを確認する必要があります。このような審査の主な理由は、セキュリティ上の懸念、不正行為、不正使用、コンプライアンス監査です。たとえば、自動ビットコイン マイニング検出機能が、ビットコイン マイニングに VM が使用されていることを検出すると、Google は問題を確認し、VM デバイス上のマルウェアが VM の容量を使い果たしていることを確認します。Google がマルウェアを削除し、VM の使用状況が正常に戻ります。
Google によるお客様データへのアクセスの制御とモニタリング
Google の内部統制には、次のものがあります。
- 不正アクセスを防止するインフラストラクチャ全体にわたる制御システム
- 継続的な制御による不正アクセスの検出と修正
- 内部監査チームと独立した第三者監査機関によるモニタリング、違反アラート、定期的な監査
Google による物理インフラストラクチャの保護の詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。
インフラストラクチャ全体の管理
Google のインフラストラクチャは、セキュリティを中核として構築されています。Google のグローバル インフラストラクチャは比較的均質であるため、Google は自動化されたインフラストラクチャを使用して制御を実装し、特権アクセスを制限できます。以降のセクションでは、特権アクセスの原則を実装するために役立つ制御について説明します。
すべてのアクセスに対する厳格な認証
Google では、ユーザー（社員など）とロール（サービスなど）によるデータへのアクセスに対して強力な認証要件が定められています。本番環境で実行されるジョブは、これらの ID を使用して、他のサービスのデータストアまたはリモート プロシージャ コール（RPC）メソッドにアクセスします。複数のジョブが同じ ID で実行されることもあります。Google のインフラストラクチャでは、特定の ID を持つジョブのデプロイや変更は、サービスを実行する担当者（一般には Google のサイト信頼性エンジニア（SRE））に制限されています。ジョブが開始されると、暗号認証情報とともにプロビジョニングされます。ジョブはこれらの認証情報を使用して、その他のサービスをリクエストするときに（Application Layer Transport Security（ALTS） を使って）その ID を証明します。
コンテキストアウェア アクセス
ゼロトラスト セキュリティを実現するため、Google のインフラストラクチャはコンテキストを使用してユーザーとデバイスの認証と承認を行います。アクセスの判断は、静的認証情報や会社のイントラネットから発信されたものかどうかだけに基づいて行われるわけではありません。リクエストの完全なコンテキスト（ユーザー ID、所在地、デバイスの所有者と設定、詳細なアクセスポリシーなど）が評価され、リクエストの有効性が判断され、フィッシング攻撃や認証情報を盗もうとするマルウェアから保護されます。
コンテキストを使用すると、各認証リクエストと認可リクエストで、セキュリティ トークンまたはその他の 2 要素認証プロトコルを使用して強力なパスワードを使用する必要があります。認証されたユーザーと信頼できるデバイスには、必要なリソースへの限定的な一時アクセス権が付与されます。マシンの在庫は安全に維持され、接続する各デバイスの状態（OS のアップデート、セキュリティ パッチ、デバイス証明書、インストールされているソフトウェア、ウイルス スキャン、暗号化ステータスなど）が評価され、潜在的なセキュリティ リスクが検出されます。
たとえば、Chrome Enterprise Premium は、従業員の認証情報が盗まれたり不正使用されたりしないようにし、接続デバイスが侵害されないようにします。Chrome Enterprise Premium では、アクセス制御をネットワーク境界から個々のユーザーとデバイスのコンテキストに移すことで、Google 社員は VPN を使用することなく、ほぼどこからでも安全に作業できます。
すべての本番環境ソフトウェアの確認と承認
Google のインフラストラクチャは、Borg というクラスタ管理システムを使用してコンテナ化されています。Binary Authorization for Borg は、本番環境のソフトウェアがデプロイ前に審査、承認されていることを確認します。これは特に、コードに機密データへのアクセスが許可されている場合に役立ちます。Borg のバイナリ認可は、コードと構成のデプロイが特定の標準を満たしていることを確認し、これらの要件が満たされていない場合はサービス オーナーに警告します。Binary Authorization for Borg は、コードが特定の基準を満たし、チェンジ マネジメント手法に従っていることを要件とします。これらの要件を満たすコードでなければユーザーデータにアクセスできないため、Google 社員が単独で（または Google 社員のアカウントを不正使用して）プログラムによってユーザーデータにアクセスするリスクが低減されています。
ログファイルにアクセスする
Google インフラストラクチャは、データアクセスとコード変更をロギングします。ロギングのタイプには次のようなものがあります。
- カスタマー ログ: Cloud Audit Logs を使用して利用できます。
管理者アクセス ログ: アクセスの透明性を使用して利用できます。
デプロイの整合性ログ: お客様データへのアクセスの監査専任の中央セキュリティ チームによってモニタリングされる例外に関する内部ログ。例外モニタリングは、機密データを保護し、本番環境の信頼性を高めるのに役立ちます。例外モニタリングは、レビューされていないソースコードや送信されていないソースコードが、誤ってまたは意図的な攻撃の結果として特権環境で実行されないようにするのに役立ちます。
インシデントの検出と対応
アクセス違反の疑いがある場合、Google は専門の内部調査チームと、機械学習、高度なデータ処理パイプライン、脅威インテリジェンス インシデントを組み合わせた手動と自動の制御を使用して検出と対応を行います。
シグナルの開発
Google の検出と対応機能のコアは脅威インテリジェンスです。これは、過去のインシデント、ネットワーク トラフィック、内部データ、システム アクセスログ、異常な動作パターン、攻撃的なセキュリティ演習の結果、その他の多くの独自のアラートを継続的に分析することで強化されています。このデータは専任チームによって分析され、Google 全体を含むシグナル（脅威インジケーター）の動的データベースが作成されます。エンジニアリング チームは、脅威インジケータを使用して、内部システムで悪意のあるアクティビティをモニタリングし、適切なスタッフに警告し、自動応答（リソースへのアクセス権の取り消しなど）を実装する専用の検出システムを開発します。
脅威の検出
脅威は主に、ログをスキャンしてログエントリを脅威インジケーターに照合することで検出されます。強力な認証により、ログ内の人間のイベント、サービス イベント、サービス権限借用イベントを区別して、実際の人間によるアクセスの調査を優先できます。ユーザーデータ、ソースコード、機密情報へのアクセスに関連するアクティビティはログに記録され、ビジネス上の正当な理由または例外が必要です。脅威には、機密システムに対して一方的な措置を講じようとする個人や、正当なビジネス上の理由なくユーザーデータにアクセスしようとする個人が含まれます。このようなアクティビティには、アラート手順が定義されています。
インシデントの調査
ポリシー違反が検出されると、コア エンジニアリング チームとオペレーション チームとは別のセキュリティ チームが独立した監督を行い、最初の調査を行います。セキュリティ チームは次のタスクを完了します。
- インシデントの詳細を確認し、アクセスが意図的なものか、意図的でない偶発的なものか、バグや構成ミスによるものか、不適切な制御の結果（侵害された従業員の認証情報を外部攻撃者が盗んで使用しているなど）かを判断します。
- アクセスが意図的または偶発的なものである場合（Google 社員がアクセス プロトコルを認識していなかった、または誤って違反したなど）、チームは問題の修正に直ちに取り組むことができます（知的財産を回復するなど）。
- 悪意のある動作が疑われる場合は、セキュリティ チームがインシデントをエスカレーションし、データやシステム アクセス ログなどの追加情報を収集して、インシデントの範囲と影響を特定します。
- 調査の結果に応じて、セキュリティ チームは追加の調査、ドキュメント化、解決のためにインシデントを送信します。極端な場合は、外部の機関または法執行機関にインシデントを報告します。
修復
セキュリティ チームは、過去のインシデントを使用して脆弱性を特定して解決し、検出機能を改善します。すべてのインシデントが記録され、メタデータが抽出されて、各エクスプロイトの特定の戦術、手法、手順が特定されます。チームは、そのデータを使用して新しい脅威インジケーターを開発したり、既存の保護を強化したり、セキュリティの改善のための機能リクエストを行ったりします。
Google によるデータへのアクセスを監視して制御するサービス
次の Google Cloud サービスを使用すると、Google によるデータへのアクセスを可視化して制御できます。
| Google Cloud サービス | 説明 |
|---|---|
アクセス承認 |
機密性の高いデータや制限付きデータがある場合は、Access Approval を使用して、承認済みの Google 管理者がサポートのためにデータにアクセスする前に、お客様の承認を要求できます。承認されたアクセス リクエストは、承認リクエストにリンクされたアクセスの透明性ログに記録されます。リクエストを承認した後、アクセスを許可する前に、Google 内で適切に権限を付与する必要があります。Access Approval をサポートするGoogle Cloud サービスの一覧については、サポートされているサービスをご覧ください。 |
アクセスの透明性 |
アクセスの透明性では、Google の承認済み担当者が組織をサポートしているときやサービス可用性を維持しているときに、その担当者による管理アクセスがログに記録されます。アクセスの透明性をサポートする Google Cloud サービスの一覧については、サポートされているサービスをご覧ください。 |
Assured Workloads |
企業で専用のリージョン サポート、認定された規制プログラム（FedRAMP、ITAR など）、EU の主権管理などのプログラムが必要な場合は、Assured Workloads を使用します。Assured Workloads には、必要なコントロール パッケージの有効化ワークフローが用意されており、有効化ワークフローでコントロール パッケージの有効期間を作成してモニタリングできます。 Google Cloud |
Cloud KMS |
Cloud EKM で Cloud KMS を使用して、暗号鍵を制御します。Cloud EKM を使用する Cloud KMS では、Google のインフラストラクチャの外部にデプロイされたサードパーティの鍵管理システムで保存、管理されている暗号鍵を使用してデータを暗号化できます。Cloud EKM を使用すると、保存データと暗号鍵の分離を維持しつつ、クラウド コンピューティングと分析のパワーを利用できます。 |
Confidential Computing |
Confidential Computing を使用して、使用中のデータを暗号化します。Google Cloud には、Confidential Computing を有効にする次のサービスが含まれています。
これらのサービスを使用すると、信頼境界を縮小して、機密データにアクセスできるリソースを減らすことができます。詳細については、 Google Cloudに Confidential Computing を実装するをご覧ください。 |
Key Access Justifications |
データ主権と検出には Key Access Justifications を使用します。 Key Access Justifications は、外部でホストされている鍵を使用してデータを復号するたびに Justification を提示します。Key Access Justifications では、データに対する管理を強化するために、Cloud KMS と Cloud HSM または Cloud KMS と Cloud EKM が必要です。Google の担当者が保存データの復号を行うには、お客様がアクセスを承認する必要があります。 |
次のステップ
- お客様のデータのプライバシー保護に対する Google の取り組みについて詳しくは、Google Cloud と一般的なプライバシー原則をご覧ください。
不正な管理者アクセスを防止する制御の基本原則については、管理アクセス制御の概要をご覧ください。
Google の担当者がデータにアクセスする際に必要となるビジネス上の理由について詳しくは、正当化理由コードをご覧ください。