Google Cloud での特権アクセス

このコンテンツの最終更新日は 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 の担当者から承認を得ている。
• アクセス承認に登録している場合は、承認を得ている。

担当者のロールによって必要なアクセスレベルは異なります。たとえば、サポートロールには、カスタマー サポート チケットに直接関連する顧客データに対して制限付きのアクセス権があります。エンジニアリング ロールでは、サービスの信頼性やサービスのデプロイに関連する複雑な問題に対処するために、追加のシステム権限が必要になる場合があります。

Google は、Google サービスを提供するためにサードパーティ（カスタマー サポート ベンダーなど）と協力する場合は、そのサードパーティが適切なレベルのセキュリティとプライバシー対策を講じているかどうかを確認しています。 Google Cloud は、サービスの提供に使用されるすべての復処理者のリストを公開しています。

Google の担当者が顧客データにアクセスする理由

Google Cloud は、Google の担当者による顧客データへのアクセスを自動化する、最小限に抑える、または排除するように設計されていますが、Google の担当者が顧客データにアクセスする必要がある場合もあります。このようなケースには、お客様からのサポート要請、サービスの停止やツールの障害、サードパーティの法的リクエスト、Google が開始した審査などがあります。

お客様からのサポート要請

アクセスの透明性を使用するサービスで Google の担当者が顧客データにアクセスするのは、通常、カスタマーケアへの連絡など、お客様が開始したイベントの結果です。問題の解決のためにカスタマーケア担当者に連絡した場合、カスタマーケア担当者は機密性の高いデータにアクセスすることはできません。たとえば、バケットへのアクセス権を失った場合、カスタマーケア担当者はバケット名などの機密性の低いデータにしかアクセスできません。

サービスの停止またはツールの障害

サービスの停止中やツールの障害発生中、Google の担当者は必要に応じて顧客データにアクセスしてバックアップや復元を行うことができます。このような場合、Google の担当者は顧客データに直接アクセスできるツールを使用して、効率を最大限に高め、問題を迅速に解決します。これらのツールは、このアクセスとエンジニアが提供した理由をログに記録します。また、アクセスは Google セキュリティ対応チームによって監査され、ログに記録されます。サポートされている Google Cloudサービスは、サービスの停止中に表示されるアクセスの透明性のログを生成します。サービスの停止中、エンジニアはリソースの許可リストをバイパスすることはできませんが、お客様の承認なしにデータにアクセスできます。

サードパーティからの法的要請

サードパーティからの法的要請はまれであり、有効な法的アクセスの正当化を生成できるのは法務チームのみです。法務チームがリクエストを確認し、リクエストが法的要件と Google のポリシーを満たしていることを確認します。また、法的に許可されている場合はお客様に通知し、法律で認められる範囲でのデータ開示に対する異議申し立てを検討します。詳細については、Cloud の顧客データに関する政府のリクエスト（PDF）をご覧ください。

Google が審査を開始

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 は、本番環境のソフトウェアがデプロイ前に審査、承認されていることを確認します。これは特に、コードに機密データへのアクセスが許可されている場合に役立ちます。Binary Authorization for Borg は、コードと構成のデプロイが特定の基準を満たしていることを確認し、これらの要件が満たされていない場合はサービス オーナーに警告します。Binary Authorization for Borg は、コードが特定の基準を満たし、チェンジ マネジメント手法に従っていることを要件とします。これらの要件を満たすコードでなければユーザーデータにアクセスできないため、Google の担当者が単独で（または Google の担当者のアカウントを不正使用して）プログラムによってユーザーデータにアクセスするリスクが低減されています。

ログファイルへのアクセス

Google インフラストラクチャは、データアクセスとコード変更をログに記録します。ロギングのタイプには次のようなものがあります。

• 顧客ログ: Cloud Audit Logs を使用して利用できます。

• 管理者権限ログ: アクセスの透明性を使用して利用できます。

• デプロイの整合性ログ: 顧客データへのアクセスの監査に従事する専任の中央セキュリティ チームによってモニタリングされる、例外に関する内部ログ。例外モニタリングは、機密データを保護し、本番環境の信頼性を高めるのに役立ちます。例外モニタリングは、レビューされていないソースコードや送信されていないソースコードが、誤ってまたは意図的な攻撃の結果として特権環境で実行されないようにするのに役立ちます。

インシデントの検出および対応

Google は専門の内部調査チームと、ML、高度なデータ処理パイプライン、脅威インテリジェンスのインシデントを組み合わせた手動と自動の制御を使用して、違反の疑いのあるアクセスを検出し、対応します。

シグナルの開発

Google の検出と対応機能のコアは脅威インテリジェンスです。これは、過去のインシデント、ネットワーク トラフィック、内部データ、システム アクセスログ、異常な動作パターン、不適切なセキュリティ演習の結果、そしてその他の多くの独自のアラートを継続的に分析することで強化されています。このデータは専任チームによって分析され、Google 全体を含むシグナルや脅威インジケーターの動的なデータベースが作成されます。エンジニアリング チームは、脅威インジケーターを使用して専用の検出システムを開発します。これにより、内部システムでの悪意のあるアクティビティのモニタリング、適切なスタッフへのアラート通知、自動応答（リソースへのアクセス権の取り消しなど）の実装を実現します。

脅威の検出

脅威は主に、ログをスキャンしてログエントリを脅威インジケーターに照合することで検出されます。強固な認証により、ログ内の人間によるイベント、サービス イベント、サービスのなりすましイベントを区別して、実際の人間によるアクセスの調査を優先できます。ユーザーデータ、ソースコード、機密情報へのアクセスを伴うアクティビティはログに記録され、ビジネス上の正当な理由または例外が要求されます。脅威には、機密システムに対して一方的な措置を講じようとする個人や、正当なビジネス上の理由なくユーザーデータにアクセスしようとする個人が含まれます。このようなタイプのアクティビティには、アラート手順が定義されています。

インシデントの調査

ポリシー違反が検出されると、コア エンジニアリング チームとオペレーション チームとは別のセキュリティ チームが独立した監督を行い、最初の調査を行います。セキュリティ チームは次のタスクを完了します。

• インシデントの詳細を確認し、アクセスが意図的なものか、意図的でない偶発的なものか、バグや構成ミスによるものか、不適切な制御の結果（従業員が不正アクセスされ、外部攻撃者がその認証情報を盗んで使用しているなど）かを判断します。
• アクセスが意図的でないもの、または偶発的なものである場合（Google の担当者がアクセス プロトコルを認識していなかった、または誤って違反したなど）、チームは問題の修正に直ちに取り組むことができます（知的財産を回復するなど）。
• 悪意のある動作が疑われる場合は、セキュリティ チームがインシデントをエスカレーションし、データやシステム アクセスログなどの追加情報を収集して、インシデントの範囲と影響を特定します。
• その調査の結果に応じて、セキュリティ チームは追加の調査、ドキュメント化、解決のためにインシデントを送信します。極端な場合は、外部の認証機関または法執行機関にインシデントを報告します。

修復

セキュリティ チームは、過去のインシデントを利用して、脆弱性の特定と解決を行い、検出機能を改善します。すべてのインシデントがドキュメント化され、メタデータが抽出されて、各エクスプロイトの特定の戦術、手法、手順が特定されます。チームはそのデータを使用して、新しい脅威インジケーターの開発、既存の保護機能の強化、セキュリティを改善するための機能リクエストを実施します。

Google によるデータへのアクセスを監視して制御するサービス

次の Google Cloud サービスを使用すると、Google によるデータへのアクセスを可視化して制御できます。

Google Cloud サービス	説明
アクセス承認	機密性の高いデータや制限付きデータがある場合は、アクセス承認を使用して、承認済みの Google 管理者がサポートのためにデータにアクセスする前に、お客様の承認を要求できます。承認されたアクセス リクエストは、承認リクエストにリンクされたアクセスの透明性ログに記録されます。リクエストを承認した後、アクセスを許可する前に、Google 内で適切に権限を付与する必要があります。アクセス承認をサポートする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 を可能にする次のサービスが含まれています。 Confidential VM: VM を使用するワークロードで使用中のデータを暗号化できます Confidential Google Kubernetes Engine Node: コンテナを使用するワークロードで使用中のデータを暗号化できます Confidential Dataflow: ストリーミング分析と ML で使用中のデータを暗号化できます Confidential Dataproc: データ処理で使用中のデータをの暗号化できます Confidential Space: 共同データ分析と ML で使用中のデータを暗号化できます これらのサービスを使用すると、信頼境界を縮小して、機密データにアクセスできるリソースを減らすことができます。詳細については、 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 の担当者が顧客データへのアクセスをリクエストする場合のビジネス上の理由の一覧を確認するには、正当化理由コードをご覧ください。