Google Cloud への継続的なアクセスに関するベスト プラクティス

Last reviewed 2025-08-08 UTC

このドキュメントでは、リソースへの継続的なアクセスを維持するための推奨事項について説明します。 Google Cloud 事業継続の目的は、停止や災害などの混乱時でも組織が不可欠な業務を維持できるようにすることです。これには、重要なサービスやインフラストラクチャが利用できない場合でも、従業員が引き続きアクセスできるようにすることが含まれます。

このドキュメントは、Identity and Access Management（IAM）と安全なアクセスへの維持を担当するセキュリティまたは信頼性の専門家を対象としています。 Google Cloudこのドキュメントは、Cloud Identity、Google Workspace、IAM 管理について理解していることを前提としています。

停止に備えて継続的なアクセスを確保するため、このドキュメントでは、実装できる推奨手順について説明します。これらの手順はすべて実施することも、一部のみ実施することもできますが、次の順序で実装することをおすすめします。

  1. 緊急アクセスを設定する: リソースへの最後の手段としてのアクセスを Google Cloud 有効にします。

    個々の事業継続要件に関係なく、すべての組織で緊急アクセスを設定することをおすすめします。Google Cloud

  2. 重要なユーザーに代替認証を提供する: 組織で シングル サインオン（SSO）を使用している場合、 外部 ID プロバイダ（IdP）に影響する中断は、従業員が認証して を使用する能力に影響する可能性があります Google Cloud。

    IdP の停止が組織に与える全体的な影響を軽減するには、ビジネスに不可欠なユーザーがリソースに引き続きアクセスできるように、 Google Cloud 代替認証を提供します。

  3. バックアップ IdP を使用する: IdP の停止時にすべてのユーザーが Google Cloud リソースにアクセスできるようにするには、フォールバック IdP を維持します。

    フォールバック IdP は中断の影響をさらに最小限に抑えるのに役立ちますが、このオプションはすべての組織にとって費用対効果が高いとは限りません。

以降のセクションでは、これらの推奨手順とベスト プラクティスについて説明します。

緊急アクセスを設定する

緊急アクセスの目的は、リソースへの最後の手段としてのアクセスを有効にし、 Google Cloud 完全にアクセスできなくなる状況を防ぐことです。

緊急アクセス ユーザーは、次のプロパティで特徴付けられます。

以降のセクションでは、緊急アクセス ユーザーを管理して保護する際に推奨されるベスト プラクティスについて説明します。

環境ごとに緊急アクセス ユーザーを作成する

本番環境のワークロードをホストする環境では、緊急 アクセスが不可欠です。 Google Cloud テストまたはステージングを目的として使用される Google Cloud 環境でも、アクセス不能になると業務が中断される可能性があります。

すべての 環境への継続的なアクセスを確保するには、 Google Cloud 環境ごとに Cloud Identity または Google Workspace で緊急アクセス ユーザーを作成して維持します。

緊急アクセスの冗長性を確保する

単一の緊急アクセス ユーザーは単一障害点です。このシナリオでは、セキュリティ キーの破損、パスワードの紛失、アカウントの強制停止により、アカウントへのアクセスが中断される可能性があります。このリスクを軽減するには、Cloud Identity アカウントまたは Google Workspace アカウントごとに複数の緊急アクセス ユーザーを作成します。

緊急アクセス ユーザーは非常に高い権限を持つため、作成しすぎないでください。 ほとんどの組織では、Cloud Identity アカウントまたは Google Workspace アカウントごとに、緊急アクセス ユーザーを 2 ～ 5 人にすることをおすすめします。

緊急アクセス ユーザーに別の組織部門を使用する

緊急アクセス ユーザーには特別な構成が必要であり、他のユーザー アカウントに適用される JML ライフサイクルの対象外です。

緊急アクセス ユーザーを通常のユーザー アカウントから分離するには、緊急アクセス ユーザー専用の組織部門（OU）を使用します。別の OU を使用すると、緊急ユーザーにのみカスタム構成を適用できます。

2 段階認証プロセスに FIDO セキュリティ キーを使用する

2 段階認証プロセスに Fast IDentity Online（FIDO） セキュリティ キーを使用します。

緊急アクセス ユーザーは Cloud Identity アカウントまたは Google Workspace アカウントで非常に高い権限を持つユーザーであるため、2 段階認証プロセスを使用してこれらのユーザーを保護する必要があります。

Cloud Identity と Google Workspace でサポートされている 2 段階認証プロセスの中で、FIDO セキュリティ キーを使用することをおすすめします。この方法は、フィッシングに対する保護と強力なセキュリティを提供します。すべての緊急アクセス ユーザーが 2 段階認証プロセスに FIDO セキュリティ キーを使用するようにするには、次の操作を行います。

ユーザーごとに複数の鍵を登録すると、セキュリティ キーの破損によるアクセス不能のリスクを軽減できます。また、緊急時にユーザーが少なくとも 1 つの鍵にアクセスできる可能性が高まります。

複数の緊急アクセス ユーザーに同じセキュリティ キーセットを使用してもかまいません。ただし、緊急アクセス ユーザーごとに異なるセキュリティ キーを使用することをおすすめします。

物理的なセキュリティ コントロールを使用して認証情報とセキュリティ キーを保護する

緊急アクセス ユーザーの認証情報とセキュリティ キーを保存する場合は、強力な保護と緊急時の可用性のバランスを取る必要があります。

  • 権限のない担当者が緊急アクセス ユーザーの認証情報にアクセスできないようにします。緊急アクセス ユーザーは、緊急時にのみこれらの認証情報を使用する必要があります。
  • 緊急時に、権限のある担当者が最小限の遅延で認証情報にアクセスできるようにします。

ソフトウェア ベースのパスワード マネージャーに依存しないことをおすすめします。代わりに、物理的なセキュリティ コントロールに依存して、緊急アクセス ユーザーの認証情報とセキュリティ キーを保護することをおすすめします。

適用する物理的なセキュリティ コントロールを選択する際は、次の点を考慮してください。

  • 可用性の向上:
    • パスワードのコピーを、異なるオフィスの複数のセキュリティ ボルトなど、複数の物理的な場所に保存します。
    • 緊急アクセス ユーザーごとに複数のセキュリティ キーを登録し、関連するオフィスごとに 1 つのキーを保管します。
  • セキュリティの強化: パスワードとセキュリティ キーを異なる場所に保存します。

パスワードのローテーションに自動化を使用しない

緊急アクセス ユーザーのパスワードのローテーションを自動化することは有益に思えるかもしれません。ただし、この自動化により、セキュリティ侵害のリスクが増加する可能性があります。緊急アクセス ユーザーには特権管理者の権限があります。特権管理者ユーザーのパスワードをローテーションするには、自動化ツールまたはスクリプトにも特権管理者の権限が必要です。この要件により、ツールが攻撃者にとって魅力的なターゲットになる可能性があります。

全体的なセキュリティ ポスチャーを弱めないようにするには、自動化を使用してパスワードをローテーションしないでください。

安全なパスワードを使用する

緊急アクセス ユーザーを保護するには、 長く安全なパスワードを使用していることを確認します。パスワードの複雑さの最小レベルを適用するには、前述のように専用の OU を使用し、 パスワード要件を実装します。

パスワードを手動でローテーションしない限り、 パスワードの有効期限を無効にします すべての緊急アクセス ユーザーの。

アクセス ポリシーから緊急アクセス ユーザーを除外する

緊急時に、コンテキストアウェア アクセス ポリシーにより、緊急アクセス ユーザーでも特定のリソースにアクセスできない状況が発生する可能性があります。このリスクを軽減するには、アクセス ポリシーのすべてのアクセスレベルから少なくとも 1 人の緊急アクセス ユーザーを除外します。

これらの除外により、緊急アクセス ユーザーの少なくとも 1 人が リソースに継続的にアクセスできるようになります。緊急時やコンテキストアウェア アクセス ポリシーの構成ミスが発生した場合でも、これらの緊急アクセス ユーザーはアクセスを維持できます。

緊急アクセス ユーザー イベントのアラートを設定する

緊急イベント以外の緊急アクセス ユーザー アクティビティは、不審な動作を示している可能性があります。緊急アクセス ユーザーの アクティビティに関連するイベントの通知を受け取るには、 Google 管理コンソールでレポートルールを作成します。 レポートルールを作成する際に、次のような条件を設定できます。

  • データソース: ユーザーのログイベント。

  • [**条件作成ツール**]（条件作成ツール）タブの**属性**: 属性と 演算子を使用して、緊急アクセス ユーザーとイベントを含む組織部門のフィルタを作成します。

    たとえば、属性と演算子を設定して、次のような条件文に似たフィルタを作成できます。

    Actor organizational unit Is /Privileged

AND

(Event Is Successful login OR Event Is Failed login OR Event Is Account
password change)

  • しきい値: count > 0 の場合は 1 時間ごと

  • アクション: メール通知を送信する

  • メールの受信者: セキュリティ チームの関連メンバーを含むグループを選択します。

重要なユーザーに代替認証を提供する

組織で SSO を使用して従業員が Google サービスを認証する場合、サードパーティの IdP の可用性が重要になります。IdP が中断すると、従業員は不可欠なツールやリソースにアクセスできなくなる可能性があります。

緊急アクセスは管理アクセスを継続的に確保するのに役立ちますが、IdP の停止時の従業員のニーズには対応していません。

IdP の中断による影響を軽減するには、重要なユーザーの認証フォールバックを使用するように Cloud Identity アカウントまたは Google Workspace アカウントを構成します。次のフォールバック プランを使用できます。

  • 通常のオペレーションでは、ユーザーは SSO を使用して認証できます。
  • IdP の停止時には、これらの重要なユーザーの SSO を選択的に無効にし、事前にプロビジョニングした Google ログイン認証情報を使用して認証できるようにします。

以降のセクションでは、外部 IdP の停止時に重要なユーザーが認証できるようにする場合に推奨されるベスト プラクティスについて説明します。

特権ユーザーに重点を置く

IdP の停止時に重要なユーザーが認証できるようにするには、ユーザーに次のような有効な Google ログイン認証情報が必要です。

  • 2 段階認証プロセス用のセキュリティ キー付きパスワード。
  • パスキー。

通常 SSO を使用するユーザーに Google ログイン認証情報をプロビジョニングすると、次のような方法で運用上のオーバーヘッドとユーザーの摩擦が増加する可能性があります。

  • IdP によっては、ユーザー パスワードを自動的に同期できない場合があります。そのため、ユーザーにパスワードを手動で設定してもらう必要がある場合があります。
  • ユーザーにパスキーの登録または 2 段階認証プロセスへの登録をリクエストする必要がある場合があります。通常、SSO ユーザーにはこの手順は必要ありません。

Google サービスへの中断のないアクセスというメリットと、追加のオーバーヘッドのバランスを取るには、特権ユーザーとビジネスに不可欠なユーザーに重点を置きます。これらのユーザーは中断のないアクセスから大きなメリットを得られる可能性が高く、ユーザー ベース全体のごく一部にすぎない可能性があります。

SSO 後の検証を有効にする機会を利用する

特権ユーザーに代替認証をプロビジョニングすると、意図しない結果としてオーバーヘッドが増加する可能性があります。このオーバーヘッドを相殺するために、これらのユーザーに対して SSO 後の検証を有効にすることもできます。

デフォルトでは、ユーザーに SSO を設定しても、2 段階認証プロセスを実行する必要はありません。この方法は便利ですが、IdP が 侵害された場合、SSO 後の検証が有効になっていないユーザーは、 認証情報の偽造攻撃の標的になる可能性があります。

SSO 後の検証は、IdP の侵害による影響を軽減するのに役立ちます。ユーザーは SSO を試行するたびに 2 段階認証プロセスを実行する必要があるためです。特権ユーザーに Google ログイン認証情報をプロビジョニングすると、SSO 後の検証により、追加のオーバーヘッドなしでこれらのユーザー アカウントのセキュリティ ポスチャーを改善できます。

特権ユーザーに別の OU を使用する

外部 IdP の停止時に認証できる特権ユーザーには、特別な構成が必要です。この構成は、通常のユーザーと緊急アクセス ユーザーの構成とは異なります。

特権ユーザーを他のユーザー アカウントから分離するには、特権ユーザー専用の OU を使用します。この別の OU を使用すると、SSO 後の検証などのカスタム ポリシーをこれらの特権ユーザーにのみ適用できます。

別の OU を使用すると、IdP の停止時に特権ユーザーの SSO を選択的に無効にすることもできます。OU の SSO を無効にするには、SSO プロファイルの割り当てを 変更します。

バックアップ IdP を使用する

IdP の停止時に重要なユーザーに代替認証を提供すると、IdP の停止が組織に与える影響を軽減できます。ただし、この軽減策では、完全な運用能力を維持するには不十分な場合があります。多くのユーザーが不可欠なアプリケーションやサービスにアクセスできなくなる可能性があります。

IdP の停止による影響をさらに軽減するには、バックアップ IdP にフェイルオーバーします。次のバックアップ プランを使用できます。

  • 通常のオペレーションでは、ユーザーは SSO とプライマリ IdP を使用して認証できます。
  • IdP の停止時には、Cloud Identity アカウントまたは Google Workspace アカウントの SSO 構成を変更して、バックアップ IdP に切り替えます。

バックアップ IdP は同じベンダーのものである必要はありません。バックアップ IdP を作成する場合は、プライマリ IdP の構成と一致する構成を使用します。バックアップ IdP で、すべてのユーザーが認証して Google サービスにアクセスできるようにするには、バックアップ IdP でプライマリ IdP のユーザー ベースの最新コピーを使用する必要があります。

バックアップ IdP は、包括的な緊急時アクセスを提供するのに役立ちます。ただし、これらのメリットと、バックアップ IdP によって発生する可能性のある追加のリスクを比較検討する必要があります。考えられるリスクは次のとおりです。

  • バックアップ IdP のセキュリティがプライマリ IdP よりも弱い場合、フェイルオーバー時に 環境全体の セキュリティ ポスチャーも 弱くなる可能性があります。 Google Cloud
  • プライマリ IdP とバックアップ IdP で SAML アサーションの発行方法が異なる場合、 IdP はユーザーをスプーフィング攻撃のリスクにさらす可能性があります。

以降のセクションでは、緊急時アクセスにバックアップ IdP を使用する場合に推奨されるベスト プラクティスについて説明します。

バックアップ IdP 用に別の SAML プロファイルを作成する

Cloud Identity と Google Workspace では、複数の SAML プロファイルを作成できます。各 SAML プロファイルは、異なる SAML IdP を参照できます。

バックアップ IdP へのフェイルオーバーに必要な作業量を最小限に抑えるには、バックアップ IdP の SAML プロファイルを事前に準備します。

既存のオンプレミス IdP を使用する

バックアップとして機能する追加の IdP をプロビジョニングする必要はありません。代わりに、既存のオンプレミス IdP をこの目的に使用できるかどうかを確認します。たとえば、 組織で Active Directory を ID の信頼できるソースとして使用し、 SSO に Active Directory フェデレーション サービス（AD FS）を使用している場合があります。このシナリオでは、AD FS をバックアップ IdP として使用できる可能性があります。

この再利用アプローチは、コストとメンテナンスのオーバーヘッドを抑えるのに役立ちます。

必要な負荷を処理できるようにバックアップ IdP を準備する

認証をバックアップ IdP に切り替える場合は、プライマリ IdP が通常処理するすべての認証リクエストを処理する必要があります。

バックアップ IdP をデプロイしてサイズ設定する場合は、想定されるリクエストの数が次の要因によって異なることに注意してください。

たとえば、セッション継続時間が 8 ～ 24 時間の場合、従業員が勤務を開始する午前中に認証リクエストが急増する可能性があります。

フェイルオーバー手順を定期的にテストする

SSO フェイルオーバー プロセスが確実に機能するようにするには、プロセスを定期的に検証する必要があります。フェイルオーバー手順をテストする際は、次の操作を行います。

次のステップ

寄稿者

著者: Johannes Passing | クラウド ソリューション アーキテクト

その他の寄稿者: Ido Flatow | クラウド ソリューション アーキテクト