ポリシーとアクセスに関する問題のトラブルシューティング

このドキュメントでは、Google Cloud アクセス ポリシーの適用管理と、アクセスに関する問題のトラブルシューティングに役立つツールの概要について説明します。このドキュメントは、組織内のユーザーが Google Cloud リソースへのアクセスに関する問題を解決できるようにするサポートチームを対象としています。

Google Cloud アクセス ポリシーの適用の管理

このセクションでは、ユーザーまたは組織管理者が実装できる、Google Cloud リソースへのアクセスに影響するポリシーについて説明します。アクセス ポリシーを実装するには、次のプロダクト / ツールの一部またはすべてを使用します。

ラベル、タグ、ネットワーク タグ

Google Cloud には、リソースにラベルを付けてグループ化する方法がいくつか用意されています。ラベル、タグ、ネットワーク タグは、ポリシーの適用をサポートするために使用できます。

ラベルは、Google Cloud リソースの整理で役立つ Key-Value ペアです。多くの Google Cloud サービスがラベルに対応しています。ラベルを使用して、他のユースケースのリソースをフィルタリング、グループ化することもできます。たとえば、本番環境にあるリソースではなく、テスト環境にあるすべてのリソースを特定できます。ポリシーの適用においては、ラベルでリソースの配置場所を識別できます。たとえば、テストとしてラベル付けされたリソースに適用するアクセス ポリシーは、本番環境のリソースとしてラベル付けされたリソースに適用するアクセス ポリシーとは異なります。

タグは、リソースを識別してポリシーを適用するための仕組みを提供する Key-Value ペアです。タグは、組織、フォルダ、プロジェクトに適用できます。また、タグは、タグが適用される階層レベルのすべてのリソースに適用されます。タグを使用すると、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでアクセス ポリシーを許可または拒否できます。ファイアウォール ポリシーでタグを使用して、Virtual Private Cloud（VPC）ネットワーク内のトラフィックを制御することもできます。トラブルシューティングでは、タグがどのように継承され、アクセス ポリシーやファイアウォール ポリシーと組み合わされるかを理解することが重要です。

ネットワーク タグは、上記のリソース管理タグとは異なります。ネットワーク タグは VM インスタンスに適用されるタグで、VM を送信先または送信元とするネットワーク トラフィックを制御するためにも使用できます。Google Cloud ネットワークでは、ファイアウォール ルールやネットワーク ルートの対象となる VM を識別するためにネットワーク タグが使用されます。ファイアウォール ルールでは、ネットワーク タグをソース値や宛先値として使用できます。また、ネットワーク タグを使用して特定のルートが適用される VM を識別することもできます。ネットワーク タグは、ネットワークやルーティング ルールの定義に使用されるため、ネットワーク タグを把握することで、アクセスに関する問題のトラブルシューティングに役立てることが可能です。

VPC ファイアウォール ルール

VPC ファイアウォール ルールを構成して、仮想マシン（VM）インスタンスと VM 上に構築されたプロダクトを送信先または送信元とするトラフィックを許可または拒否できます。すべての VPC ネットワークは分散ファイアウォールとして機能します。VPC ファイアウォール ルールはネットワーク レベルで定義されますが、接続はインスタンスごとに許可または拒否されます。VPC ファイアウォール ルールは、VPC ネットワーク、タグでグループ化された VM、サービス アカウントでグループ化された VM に適用できます。

VPC Service Controls

VPC Service Controls は、Cloud Storage や BigQuery などの Google Cloud サービスからのデータ漏洩を防止するのに役立つ境界セキュリティ ソリューションです。Google Cloud リソースの周囲にセキュリティ境界を構築するサービス境界を作成して、この境界の内外に配置できるリソースを管理できます。VPC Service Controls では、IP アドレスや ID などのコンテキスト属性に基づいてポリシーを実装することでコンテキストアウェア アクセス制御を行うこともできます。

Resource Manager

Resource Manager を使用して、組織のリソースを設定できます。Resource Manager は、組織とアプリケーションの開発方法をリソース階層にマッピングするためのツールです。リソースを論理的にグループ化するのに役立つ Resource Manager では、アクセス制御ポリシーと組織のポリシーの接続ポイントを提供し、継承を可能にします。

Identity and Access Management

Identity and Access Management（IAM）では、どのユーザー（ID）に、どのリソースに対するどのようなアクセス権（ロール）を付与するのかを定義できます。IAM ポリシーは、読み取りアクセス権や書き込みアクセス権など、誰がどのアクセス権を持っているかを定義するステートメントの集合です。IAM ポリシーはリソースに関連付けられます。ユーザーがそのリソースにアクセスしようとするたびに、ポリシーによってアクセス制御が適用されます。

IAM 条件は IAM の機能の一つです。ポリシー定義の一環として IAM 条件を実装した場合、構成された条件が満たされている場合にのみ、ID（メンバー）にリソース アクセス権を付与できます。たとえば、IAM 条件を使用して、企業のオフィスからリクエストを送信する従業員のみにリソースへのアクセスを制限できます。

組織ポリシー サービス

組織ポリシー サービスを使用すると、組織の階層全体で対応しているリソースに対して制約を適用できます。組織のポリシーの対象になっている各リソースには、リソースの制限方法を説明する一連の制約があります。リソースの構成を制限する特定のルールを定義するポリシーを定義します。

権限のある管理者は組織ポリシー サービスを使用して、フォルダレベルまたはプロジェクト レベルで必要に応じてデフォルトの組織のポリシーをオーバーライドできます。組織のポリシーは、リソースの構成方法に焦点を置いていますが、IAM ポリシーは、それらのリソースに対するどのような権限が ID に付与されているかに焦点を置いています。

割り当て

Google Cloud では、リソースに割り当てが適用されます。これにより、プロジェクトで使用できる特定の Google Cloud リソースの量に上限が設定されます。所有するプロジェクトの数にも割り当てが適用されます。次のタイプのリソースの使用量は、割り当てにより制限されます。

  • レートに基づく割り当て。1 日あたりの API リクエストの数など。このような割り当ては、1 分や 1 日など、指定された時間が経過するとリセットされます。
  • 数量に基づく割り当て。プロジェクトで使用されている仮想マシンやロードバランサの数など。このような割り当ては、時間が経過してもリセットされません。リソースを使用する必要がなくなったら、Google Kubernetes Engine（GKE）クラスタを削除するなどして、割り当てを明示的に解放する必要があります。

数量に基づく割り当ての上限に達すると、新しいリソースを起動できなくなります。レートに基づく割り当ての上限に達すると、API リクエストを完了できなくなります。これらの問題は、いずれもアクセス関連の問題のように見える可能性があります。

BeyondCorp Enterprise

BeyondCorp Enterprise は、さまざまな Google Cloud プロダクトを使用して、ユーザーの ID とリクエストのコンテキストに基づいてきめ細かいアクセス制御を適用します。Google Cloud コンソールと Google Cloud APIs へのアクセスを制限するように、BeyondCorp Enterprise を構成できます。

BeyondCorp Enterprise アクセス保護は、次の Google Cloud サービスを使用して機能します。

  • Identity-Aware Proxy（IAP）: ユーザー ID を確認し、コンテキストを使用して、ユーザーにリソースへのアクセス権を付与するかどうかを決定するサービス。
  • IAM: Google Cloud の ID を管理および承認するためのサービス。
  • Access Context Manager: きめ細かなアクセス制御を有効にするルールエンジン。
  • Endpoint Verification: ユーザーのデバイスの詳細情報を収集する Google Chrome 拡張機能。

IAM Recommender

IAM に含まれている Policy Intelligence ツールを使用すると、Google Cloud を使用する際の効率性と安全性を高める包括的なプロアクティブ ガイダンスを参照できます。推奨されるアクションは、コンソールで通知によって提供されます。このアクションは、直接適用することも、Pub/Sub トピックに送信されたイベントを使用して適用することもできます。

IAM Recommender は、Policy Intelligence スイートの一部であり、これを使用して最小権限の原則の適用に役立てることができます。Recommender は、各メンバーが過去 90 日間に使用した権限とプロジェクト レベルのロール付与を比較します。あるメンバーにプロジェクト レベルのロールを付与した後、そのメンバーがそのロールのすべての権限を使用していない場合に、Recommender がロールの取り消しを推奨することがあります。また、Recommender は、必要に応じて権限の低いロールへの変更を提案します。

提案を自動的に適用すると、ユーザーまたはサービス アカウントが意図せずリソースにアクセスできなくなってしまう場合があります。自動化を使用する場合は、IAM Recommender のベスト プラクティスに従って適切な自動化レベルを判断することをおすすめします。

Kubernetes Namespace と RBAC

Kubernetes は Google Kubernetes Engine（GKE）という名前で、Google Cloud 上のマネージド サービスとして運用されています。GKE では、GKE クラスタが実行されている場所に関係なく、一貫したポリシーを適用できます。リソースへのアクセス権に影響するポリシーは、組み込みの Kubernetes コントロールと Google Cloud 固有の制御の組み合わせです。

VPC ファイアウォールと VPC Service Controls に加えて、GKE は Namespace、ロールベースのアクセス制御（RBAC）、ワークロード ID を使用して、リソースへのアクセスに影響するポリシーを管理します。

Namespace

Namespace は、同じ物理クラスタを基盤とする仮想クラスタであり、名前のスコープを提供します。リソース名は Namespace 内で一意である必要がありますが、異なる Namespace で同じ名前を使用できます。Namespace を使用すると、リソース割り当てを使用して複数のユーザー間でクラスタ リソースを分割できます。

RBAC

RBAC には次の機能が含まれます。

  • クラスタ上で稼働している API リソースにユーザーがアクセスする方法をきめ細かく制御できます。
    • きめ細かいポリシーを作成して、ユーザーとサービス アカウントがアクセス可能なオペレーションとリソースを定義できます。
    • Google アカウント、Google Cloud サービス アカウント、Kubernetes サービス アカウントへのアクセスを制御できます。
  • クラスタ全体またはクラスタ内の特定の Namespace に適用される RBAC 権限を作成できます。
    • クラスタ全体の権限は、特定のユーザーの特定の API リソースへのアクセスを制限する場合に便利です。これらの API リソースには、セキュリティ ポリシーとシークレットが含まれます。
    • Namespace 固有の権限は、複数のユーザー グループがそれぞれの Namespace 内で作業している場合などに便利です。RBAC は、ユーザーが自分の Namespace 内のクラスタ リソースにのみアクセスできるようにする場合に役立ちます。
  • 単一の Namespace 内のリソースへのアクセスを許可するためにのみ使用できるロール。
  • 一連の権限を表すルールを含む Role権限は純粋に付加的なものであり、拒否ルールはありません。

IAM と Kubernetes RBAC は統合されているため、いずれかのツールにより、十分な権限があるユーザーに操作の実行が許可されます。

図 1 は、IAM で RBAC と Namespace を使用してポリシーを実装する方法を示しています。

図 1.IAM と Kubernetes RBAC が連携して GKE クラスタへのアクセスを制御します。

図 1 は、次のポリシーの実装を示しています。

  1. プロジェクト レベルで、IAM は、クラスタ管理者がクラスタを管理し、コンテナ デベロッパーがクラスタ内の API にアクセスできるようにするロールを定義します。
  2. クラスタレベルで、RBAC は個々のクラスタに対する権限を定義します。
  3. Namespace レベルで、RBAC は Namespace に対する権限を定義します。

Workload Identity

RBAC と IAM に加えて、Workload Identity の効果についても理解する必要があります。Workload Identity を使用すると、Google サービス アカウントとして機能するように Kubernetes サービス アカウントを構成できます。Kubernetes サービス アカウントとして実行されるアプリケーションは、Google Cloud APIs にアクセスするとき自動的に Google サービス アカウントとして認証されます。この認証により、クラスタ内のアプリケーションにきめ細かい ID と認可の割り当てを行うことができます。

Workload Identity は、IAM 権限を通じて、GKE アプリケーションがアクセスできる Google Cloud APIs を制御します。たとえば、IAM 権限が変更されると、GKE アプリケーションが Cloud Storage に書き込めなくなる場合があります。

トラブルシューティング ツール

このセクションでは、ポリシーのトラブルシューティングに役立つツールについて説明します。ポリシーを組み合わせて適用する際に、さまざまなプロダクトや機能を使用できます。たとえば、ファイアウォールとサブネットを使用して、自身の環境内のリソースと定義済みのセキュリティ ゾーン間の通信を管理できます。また、IAM を使用して、セキュリティ ゾーン内および定義済みの VPC Service Controls ゾーン内でどのユーザーが何にアクセスできるかを制限することもできます。

ログ

通常、問題が発生した場合に、トラブルシューティングのために最初に行うことはログの確認です。アクセス関連の問題の分析情報を確認できる Google Cloud のログは、Cloud Audit Logs、ファイアウォール ルール ロギング、VPC フローログです。

Cloud Audit Logs

Cloud Audit Logs は、プロジェクト、フォルダ、組織ごとに、管理アクティビティ、データアクセス、システム イベントの監査ログストリームで構成されます。これらのログには Google Cloud サービスによって監査ログエントリが書き込まれるため、Google Cloud プロジェクト内で誰が、何を、どこで、いつ行ったかを確認できます。

  • 管理アクティビティ ログには、リソースの構成またはメタデータを変更する API 呼び出しなどの管理操作に関するログエントリが含まれます。管理アクティビティ ログは常に有効です。管理アクティビティ ログの料金と割り当ての詳細については、Cloud Audit Logs の概要をご覧ください。
  • データアクセス ログには、ユーザー提供データを作成、変更、または読み取る API 呼び出しが記録されます。BigQuery を除き、データアクセス監査ログはデフォルトで無効になっています。データアクセス ログは大きくなる可能性があり、費用が発生する可能性があります。データアクセス ログの使用量上限については、割り当てと上限をご覧ください。発生する可能性のある費用については、料金をご覧ください。
  • システム イベント ログには、Compute Engine によって実行されたシステム イベントに関するログエントリが記載されます。たとえば、各ライブ マイグレーションがシステム イベントとして記録されます。システム イベント ログの料金と割り当てについては、Cloud Audit Logs の概要をご覧ください。

Cloud Logging では、protoPayload フィールドに、監査ログデータを格納する AuditLog オブジェクトが含まれています。監査ログエントリの例については、監査ログエントリのサンプルをご覧ください。

管理アクティビティ監査ログを表示するには、ログ閲覧者のロール（roles/logging.viewer）または基本閲覧者のロール（roles/viewer）が必要です。できる限り、タスクを完了するために必要な最小権限を持つロールを選択します。

個々の監査ログエントリは、指定した期間保存されます。長時間保持したい場合は、Cloud Storage、BigQuery、または Pub/Sub にログエントリをエクスポートできます。組織のすべてのプロジェクト、フォルダ、請求先アカウントからログエントリをエクスポートするには、集約エクスポートを使用します。集約エクスポートでは、組織全体のログを一元的に確認できます。

監査ログを使ってトラブルシューティングを行う手順は次のとおりです。

ファイアウォール ルールのロギング

ファイアウォール ルールロギングにより、ファイアウォール ルールの効果を監査、検証、分析できます。たとえば、トラフィックを拒否するように設計されたファイアウォール ルールが意図したとおりに機能しているかどうかを判別できます。

ファイアウォール ルールに一致する接続をログに記録する必要がある場合、そのファイアウォール ルールに対してファイアウォール ルールロギングを個別に有効にします。ルールの動作（許可または拒否）や方向（上り、内向きまたは下り、外向き）に関係なく、あらゆるファイアウォール ルールに任意でファイアウォール ルール ロギングを有効にできます。ファイアウォール ルール ロギングでは、大量のデータが生成される可能性があります。ファイアウォール ルール ロギングには料金が関連付けられているため、ログに記録する接続は慎重に計画する必要があります。

ファイアウォール ログの保存先を決定します。組織全体でログを確認する場合は、監査ログと同じシンクにファイアウォール ログをエクスポートします。特定のファイアウォール イベントを検索するには、フィルタを使用します。

ファイアウォール インサイト

ファイアウォール インサイトは、VPC ネットワークでのファイアウォールの使用状況に関する情報と、さまざまなファイアウォール ルールが与える影響についてのレポートを提供します。ファイアウォール インサイトを使用して、ファイアウォール ルールが意図した接続を許可またはブロックしていることを確認できます。

また、ファイアウォール インサイトを使用して、他のルールによって隠されているファイアウォール ルールを検出することもできます。シャドウルールとは、IP アドレス範囲やポートなど、関連するすべての属性が、より高いまたは等しい優先度を持つ 1 つ以上の他のファイアウォール ルールの属性と重複するファイアウォール ルールのことです。シャドウルールは、ファイアウォール ルール ロギングを有効にしてから 24 時間以内に計算されます。

ファイアウォール ルール ロギングを有効にすると、ファイアウォール インサイトによってログが分析され、指定したモニタリング期間（デフォルトでは過去 24 時間）に使用されていた拒否ルールの分析情報が表示されます。拒否ルールの分析情報は、ファイアウォールのパケット ドロップのシグナルとなります。パケット ドロップのシグナルを使用して、パケットのドロップが想定されたものか（セキュリティ保護などによるドロップ）か、そうでないのか（ネットワークの構成ミスなど）を確認できます。

VPC フローログ

VPC フローログは、VM インスタンスによって送受信されるネットワーク フローのサンプルを記録します。VPC フローログでは、VM に影響するトラフィックがカバーされます。すべての下り（外向き）トラフィックは、ファイアウォールの下り（外向き）拒否ルールによってブロックされていても記録されます。上り（内向き）トラフィックは、ファイアウォールの上り（内向き）許可ルールによって許可されている場合に記録されます。ファイアウォールの上り（内向き）拒否ルールによってブロックされた上り（内向き）トラフィックは記録されません。

フローログは、各 VM 接続ごとに特定の間隔で収集されます。特定の接続について特定の間隔（集計間隔）で収集されたすべてのサンプル パケットは、単一のフローログ エントリに集計されます。その後、ログフロー エントリが Cloud Logging に送信されます。

VPC フローログは、各 VPC サブネットごとに有効または無効にできます。VPC フローログを有効にすると、大量のデータが生成されます。VPC フローログを有効にするサブネットを慎重に管理することをおすすめします。たとえば、開発プロジェクトで使用されるサブネットでは、長期間フローログを有効にしないことをおすすめします。Cloud Logging またはエクスポートされたシンクを使用して、VPC フローログを直接クエリできます。認識されたトラフィック関連の問題のトラブルシューティングを行う場合には、VPC フローログを使用すると、トラフィックが想定されたポートを介して VM を出入りしているか確認できます。

アラート

アラートを使用すると、Google Cloud リソースへのアクセスに影響する可能性のあるポリシー違反のイベントが発生した場合に、適切なタイミングで通知を受け取ることができます。

リアルタイムの通知

Cloud Asset Inventory は、Google Cloud アセット メタデータの 5 週間分の履歴を保持します。アセットは、サポートされる Google Cloud リソースです。サポートされるリソースには、IAM、ファイアウォール ルールや GKE Namespace などのネットワーク機能に関連する Compute Engine、ロールとクラスタのロール バインディングが含まれます。上のリソースはすべて、Google Cloud リソースへのアクセス権に影響します。

ファイアウォール ルールや転送ルールなど、リソース構成からの差分をモニタリングするには、リアルタイム通知に登録します。リソース構成が変更されると、Pub/Sub を介してリアルタイム通知がすぐに送信されます。通知では、サポートコールに先んじて問題を早期に警告することができます。

Cloud Audit Logs と Cloud Functions

リアルタイム通知を補うため、Cloud Logging をモニタリングして、機密アクションの呼び出しに関するアラートを確認します。たとえば、組織レベルで SetIamPolicy への呼び出しをフィルタリングする Cloud Logging シンクを作成できます。シンクは、Cloud Functions の関数のトリガーに使用できる Pub/Sub トピックにログを送信します。

接続テスト

アクセスの問題がネットワーク関連か権限関連かを判断するには、Network Intelligence Center の接続テストツールを使用します。接続テストは、静的な構成の分析と診断を行うツールで、ソース エンドポイントと宛先エンドポイントの間の接続を確認できます。接続テストは、Google Cloud ネットワークの構成に関連するネットワーク関連のアクセスの問題の根本原因を特定するのに役立ちます。

接続テストでは、VPC ネットワーク、VPC ネットワーク ピアリング、オンプレミス ネットワークへの VPN トンネルを含めてテストを実行します。たとえば、接続テストにより、ファイアウォール ルールで接続がブロックされていることが特定できる場合があります。詳しくは、一般的なユースケースをご覧ください。

Policy Troubleshooter

Google Cloud の多くのタスクには、IAM ロールとそれに関連する権限が必要です。ロールに含まれている権限を確認し、タスクの実行に必要な権限かどうか確認することをおすすめします。たとえば、Compute Engine イメージを使用してインスタンスを作成する場合、ユーザーには 9 つの権限を含む compute.imageUser ロールが必要です。そのため、ユーザーは 9 つの権限すべてを含むロールと権限の組み合わせを持つ必要があります。

Policy Troubleshooter は、ユーザーまたはサービス アカウントにリソースへのアクセス権限がない理由をデバッグするための Google Cloud コンソール ツールです。アクセス権に関する問題のトラブルシューティングを行うには、Policy Troubleshooter の IAM 部分を使用します。

たとえば、特定のユーザーがプロジェクトのバケットにオブジェクトを作成できて、別のユーザーが作成できない理由を確認する場合などがあります。Policy Troubleshooter では、最初のユーザーにはあり、2 番目のユーザーにはない権限を確認できます。

Policy Troubleshooter には、次の入力が必要です。

  • プリンシパル（個々のユーザー、サービス アカウント、またはグループ）
  • 権限（IAM ロールではなく、基盤となる権限）
  • リソース

IAM Recommender

上の Recommender のセクションで説明したように、IAM Recommender はポリシー適用管理ツールですが、トラブルシューティング ツールとして使用することもできます。Recommender は、過去 60 日間の IAM アクセス ログデータと権限を分析するジョブを毎日実行します。Recommender を使用して、以前に許可されたリソースへのユーザーのアクセスに影響を与える可能性のある推奨事項が最近承認され、適用されたかどうかを確認できます。その場合、削除された権限を付与できます。

カスタマーケアへのエスカレーション

アクセス関連の問題を解決するには、適切な内部サポート プロセスと、Cloud カスタマーケアへのエスカレーションを適切に行うための明確なプロセスを用意しておくことが重要です。このセクションでは、サポート設定の例と、カスタマーケアに連絡して問題を迅速に解決する方法を説明します。

このドキュメントで説明されているツールで問題を解決できない場合、明確に定義されたサポート プロセスがあると、カスタマーケアでの問題解決を円滑に進めることができます。トラブルシューティングを行う場合は、Google の『Site Reliability Engineering (SRE)』の効果的なトラブルシューティングの章に記載されている、体系的なアプローチをとることをおすすめします。

内部サポートのプロセスでは、以下を行うことをおすすめします。

  • 問題が発生した場合のその後の手順の詳細を記述する。
  • 明確なエスカレーション パスを定義する。
  • オンコール プロセスを設定する。
  • インシデント対応計画を作成する。
  • バグ トラッキング システムやヘルプデスク システムを設定する。
  • サポート担当者からカスタマーケアへの連絡が許可され、連絡先の担当者として指定されていることを確認する。
  • Google Cloud の担当者への連絡方法など、サポート プロセスを社内スタッフに伝える。
  • サポートの問題を定期的に分析し、学習に基づいたイテレーションと改善を行う。
  • 標準化された事後フォームを用意する。

カスタマーケアにエスカレーションする必要がある場合は、アクセスの問題を解決する際に、以下の情報をカスタマーケアと共有できるようにします。

  • アクセスをリクエストしている ID（ユーザーまたはサービス アカウントのメールアドレス）。
    • この問題がすべての ID に影響するか、一部の ID に影響するか。
    • 影響を受ける ID が一部のみの場合は、影響を受ける ID と受けない ID の例を提供します。
  • ID が最近再作成されたかどうか。
  • ユーザーがアクセスしようとしているリソース（プロジェクト ID を含む）。
  • 呼び出されているリクエストまたはメソッド。
    • リクエストとレスポンスのコピーを提供します。
  • アクセスを行う ID に付与されている権限。
    • IAM ポリシーのコピーを提供します。
  • ID がリソースにアクセスしようとしているソース（ロケーション）。たとえば、Google Cloud リソース（Compute Engine インスタンスなど）、Google Cloud コンソール、Google Cloud CLI、Cloud Shell、オンプレミスやインターネットなどの外部ソースなど。
    • ソースが別のプロジェクトの場合は、ソース プロジェクト ID を提供します。
  • エラーが初めて発生した時刻（タイムスタンプ）と、問題が引き続き発生しているかどうか。
  • ID がリソースに正常にアクセスしていることを最後に確認した時刻（タイムスタンプを含む）。
  • 問題発生前に行われたすべての変更（タイムスタンプも含む）
  • Cloud Logging に記録されたエラー。カスタマーケアに情報を提供する前に、アクセス トークン、認証情報、クレジット カード番号などのセンシティブ データを秘匿化してください。

次のステップ