2026/6/8 より Google Cloud セッション有効期限のデフォルトが「無期限」から「16 時間」に - 変更による効果と影響を解説

はじめに

2026/5/1 に Google から「[Action Advised] Review customers' Google Cloud default session length value」というタイトルのメールが配信されました。

要点をひと言でまとめると、 2026/6/8 から、ユーザー認証で取得した Google Cloud 向けセッションの有効期限のデフォルト値が「無期限」から「16 時間」に変更される という内容です。

これにより、gcloud auth login や gcloud auth application-default login で取得した認証情報、特にその中に含まれる リフレッシュトークンが永続的に有効である ことに起因していた情報漏洩時の攻撃リスクが大幅に低減されます。

本ブログでは、

• これまでの認証情報の取り扱いに内在していたリスク
• 今回の変更によるセキュリティ強化と運用への影響
• 本変更を待たずに任意の値でセッション期限や再認証方式を設定する方法

について整理します。

Google からの公式アナウンス

以下、配信されたメール原文です。

We are writing to let you know that starting June 8, 2026, we'll update the default value of Google Cloud sessions from Never Expire to 16 hours for all human users within your customers' organization.

Session length management is critical for Cloud Security and Compliance. It ensures that access to Google Cloud is finite after successful authentication. A defined, finite session length significantly helps reduce the impact of security threats, such as cookie theft.

We've provided additional information below to guide you and your customers through this change.

What you need to know
This default value won't impact REST API or third-party apps.

Key changes:

Once the default session length value changes, here is how it will affect user access to Google Cloud services:

Re-authentication frequency: Users in your customers' organizations will be asked to perform re-authentication every 16 hours when accessing Google Cloud services.
Re-authentication methods: Users in your customers' organizations can re-authenticate by:
Retyping their password
Performing second factor authentication (if they have configured one)
Touching their security key (if they have configured one)
Affected surfaces: This applies to services accessed through the following surfaces:
Google Cloud Console
Google Cloud CLI

What you need to do

No action is required from your customers to get the default value for Google Cloud session control.

However, if they wish to opt out of this update and keep their current session settings, please have them submit this Google form by May 29, 2026.

Note: If your customers don't opt out before this date, we will automatically change the Google Cloud session control to 16 hours starting June 8, 2026.

Google Cloud Administrators can configure the session length parameter by following the steps described in the Configure session controls for re-authentication guide.

We're here to help

You can learn more about the Google Cloud session control in our Google Cloud Updates blog post. If you have any questions or require assistance, please visit the Partner Support Desk.

Thanks for choosing Google Cloud.

– The Google Cloud Team

変更内容のサマリー

メールの内容を表に整理します。

具体的なイメージとしては、今まではローカル環境で一度 gcloud auth login や　 gcloud auth application-default login で認証すれば、その後は再認証なしに gcloud コマンドや ADC 認証を利用するアプリを使い続けられていましたが、変更後は 16 時間が経過すると認証エラーが発生し、再度パスワードなどによる再認証が必要となります。

変更の対象となる組織は Google Workspace または Cloud Identity の管理コンソールから確認できます。 [セキュリティ] > [アクセスとデータ管理] > [Google Cloud セッションの管理] > [Google Cloud コンソールおよび SDK のセッション管理] > [再認証ポリシー] の設定が 「再認証を要求しない」 となっている場合は変更の対象となります。

変更の対象となる組織の設定

オプトアウトを行わない場合、2026/6/8 以降は自動的に 16 時間の有効期限が適用されます。なお、本設定は 1 時間〜24 時間の範囲で任意の値に変更することも可能 です。任意の値で設定する方法については後述します。

Google Cloud のユーザー認証情報の扱いと内在しているリスク

ここからは gcloud auth login や gcloud auth application-default login によるユーザー認証情報の取り扱いと、内在しているリスクについて説明します。

gcloud auth login

gcloud auth login は、 ローカル環境から Google Cloud CLI(gcloud コマンド) を実行する際の認証情報を取得するコマンド です。OAuth 2.0 のフローでユーザーが Google アカウントの認証と認可を行うと、ローカル環境にユーザーの認証情報が保存されます。

実行すると、ブラウザでの認証と認可のフローを経て以下のような出力が得られます。

$ gcloud auth login

Your browser has been opened to visit:
    https://accounts.google.com/o/oauth2/auth?...

You are now logged in as [user@example.com].
Your current project is [your-project-id].

このとき、ローカル環境には以下のファイルが作成、または更新されます。

credentials.db は SQLite データベースのため一部バイナリ混じりですが、 cat で中身を覗くと、 アカウントごとの認証情報が JSON 形式で平文のまま読み取れる ことが確認できます。

$ cat ~/.config/gcloud/credentials.db
...(SQLite ヘッダなどのバイナリ)...{
  "client_id": "xxxxxxxxxxxx.apps.googleusercontent.com",
  "client_secret": "xxxxxxxxxxxxxxxxxxxx",
  "refresh_token": "1//0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "revoke_uri": "https://oauth2.googleapis.com/revoke",
  "scopes": [
    "openid",
    "https://www.googleapis.com/auth/userinfo.email",
    "https://www.googleapis.com/auth/cloud-platform",
    "https://www.googleapis.com/auth/appengine.admin",
    "https://www.googleapis.com/auth/sqlservice.login",
    "https://www.googleapis.com/auth/compute",
    "https://www.googleapis.com/auth/accounts.reauth"
  ],
  "token_uri": "https://oauth2.googleapis.com/token",
  "type": "authorized_user",
  "universe_domain": "googleapis.com"
}...(後略)...

gcloud コマンドは、このファイルに保存されたリフレッシュトークンを client_id / client_secret とともに Google の認可サーバー(oauth2.googleapis.com の OAuth 2.0 トークンエンドポイント)に送ることで、デフォルト 1 時間の期限付きアクセストークンを取得し、このアクセストークンを利用して Google Cloud にアクセスします。
アクセストークンが期限切れとなっても、ローカルのリフレッシュトークンが有効な間は同様の手順でアクセストークンを何度でも再発行できるため、再認証なしでアクセスを継続できます。Google Cloud セッションの組織設定が「再認証を要求しない」となっていると、リフレッシュトークン自体に期限がないため、半永久的にアクセスを継続することが可能になります。

そのため、~/.config/gcloud/credentials.db の漏洩は、攻撃者に対してユーザー権限での永続的なアクセスを提供してしまうリスクがあります。

gcloud auth application-default login

gcloud auth application-default login は、 ローカル環境のアプリケーションが Google Cloud API を呼び出すための ADC (Application Default Credentials) を構成するコマンド です。Google Cloud の各種クライアントライブラリや Terraform Google Provider など、 ADC を参照するアプリケーションが API を呼び出す際に利用されます。

実行すると、ブラウザでの認証と認可のフローを経て以下のような出力が得られます。

$ gcloud auth application-default login

Your browser has been opened to visit:
    https://accounts.google.com/o/oauth2/auth?...

Credentials saved to file: [/Users/example/.config/gcloud/application_default_credentials.json]

These credentials will be used by any library that requests Application Default Credentials (ADC).

このとき、ローカル環境には以下のファイルが作成、または更新されます。

application_default_credentials.json は JSON 形式のテキストファイルで、client_id / client_secret / リフレッシュトークンが平文のまま読み取れます。

$ cat ~/.config/gcloud/application_default_credentials.json
{
  "account": "",
  "client_id": "xxxxxxxxxxxx.apps.googleusercontent.com",
  "client_secret": "xxxxxxxxxxxxxxxxxxxx",
  "refresh_token": "1//0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "type": "authorized_user",
  "universe_domain": "googleapis.com"
}

ADC を参照するアプリケーション(Google Cloud のクライアントライブラリや Terraform Google Provider など)は、このファイルに保存された client_id / client_secret / リフレッシュトークンを利用して 1 時間の時限付きアクセストークンを取得し、Google Cloud にアクセスします。

先ほどの ~/.config/gcloud/credentials.db と同様で、アクセストークンが期限切れとなっても、ローカルのリフレッシュトークンが有効な間は同様の手順でアクセストークンを何度でも再発行できます。

よって ~/.config/gcloud/application_default_credentials.json の漏洩も、攻撃者に対してユーザー権限での永続的なアクセスを提供してしまうリスクがあります。

今回の変更によって得られる効果

gcloud auth login や gcloud auth application-default login でユーザー認証を経て取得したリフレッシュトークンは、取得時点から 16 時間が経過すると Google 側でアクセストークンへの交換が拒否される ようになります。これにより、 ファイル単位で認証情報が漏洩したとしても、ユーザーの再認証なしには攻撃者がアクセストークンを取得し続けることはできなくなります。

ただし、ユーザー認証から 16 時間の間は攻撃可能である点は引き続き留意しておく必要があります。

ユーザーへの影響

Google Cloud Console / gcloud CLI

セッションの 16 時間経過後、Google Cloud Console や gcloud の利用時に再認証が要求されます。

1 日の業務時間をカバーし、翌朝には再認証が必要となる、という運用感です。再認証はパスワードまたはセキュリティキーで完了するため、運用負荷としては大きくないと考えられます。

ADC を利用するアプリケーションへの影響

特に注意が必要なのは、 gcloud auth application-default login で取得したユーザー認証情報を、CI/CD などの非対話的なワークロードに利用しているケース です。これまで「無期限」のリフレッシュトークンに依存していたパイプラインは、 16 時間経過後のリフレッシュ失敗で停止します。

そもそも、ユーザー認証情報を非対話的なワークロードで使い回すこと自体が Google Cloud の認証ベストプラクティスとしては非推奨であり、今回の変更を機に、Workload Identity Federation などを利用した適切な認証方式へ置き換えていくことをおすすめします。

認証方式の切り替えが困難な場合、組織の特権管理者によって例外的にこれらのアプリを組織の「信頼済みリスト」に追加することは可能です。これにより、アプリはセッション期限の制約から除外されます。信頼済みリストの追加に関しては以下ドキュメントをご参照ください。

https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=ja

ADC のユーザー認証情報を利用するスクリプトやツールが残っていないかを、変更日までに棚卸ししておくことを強く推奨します。

変更を待たずに設定する、または設定変更する

今回の変更を待たずに 個別に手動で設定したい場合、または 有効期限や再認証方法を変更したい場合 は、Google Workspace または Cloud Identity の管理コンソールから、組織部門(OU)単位での設定が可能です。

組織部門ごとに異なるセッション期限を設定することも可能です。

設定手順

特権管理者で Google Workspace または Cloud Identity の管理コンソールにログインします。

[セキュリティ] > [アクセスとデータ管理] > [Google Cloud セッションの管理] から対象の組織部門(OU) を選択します。「再認証を要求する」を選択し、[再認証を要求する間隔] を変更します。また、[再認証方法]を必要に応じて変更します。信頼できるアプリをセッション期限の対象外とするには「信頼できるアプリは免除する」を有効化します。

おわりに

2026/6/8 のデフォルト値変更により、Google Cloud のリフレッシュトークンに対して有効期限が設けられることになります。

これまで gcloud auth login や gcloud auth application-default login で取得した認証情報ファイルが漏洩した場合、明示的に revoke するまで永続的にアクセスを許してしまうという大きなリスクがありましたが、変更後は最長でも 16 時間で攻撃者のアクセスは遮断されるようになります。

一方で、ユーザー認証による ADC を非対話的なワークロードで利用しているような構成では、 そのままでは動作しなくなる ため、Workload Identity Federation などへの変更、あるいは「信頼できるアプリ」での例外設定が必要となります。今回の変更を機に、組織の認証情報の管理方針を改めて見直すきっかけにしていただければと思います。