このドキュメントでは、 Google Cloud リソースへの継続的なアクセスを維持するための推奨事項について説明します。事業継続の目的は、停電や災害などの混乱が発生した場合でも、組織が重要な業務を維持できるようにすることです。この目標には、重要なサービスとインフラストラクチャが利用できない場合でも従業員がアクセスを継続できるようにすることが含まれます。
このドキュメントは、Identity and Access Management（IAM）と Google Cloudへの安全なアクセスの維持を担当するセキュリティまたは信頼性の専門家を対象としています。このドキュメントは、Cloud Identity、Google Workspace、IAM 管理に精通していることを前提としています。
このドキュメントでは、停止に備えて継続的なアクセスを確保するために実装できる、次の推奨手順について説明します。これらの手順はすべて実行することも、一部のみ実行することもできますが、次の順序で実装することをおすすめします。
緊急アクセスを設定する:Google Cloud リソースへの最終手段のアクセスを有効にします。
個々のビジネス継続性の要件に関係なく、すべてのGoogle Cloud 組織に緊急アクセスを設定することをおすすめします。
重要なユーザー向けの認証方法を準備する: 組織でシングル サインオン（SSO）を使用している場合、外部 ID プロバイダ（IdP）に影響する障害が発生すると、従業員がGoogle Cloudを認証して使用できなくなる可能性があります。
IdP の停止が組織に与える影響を軽減するには、業務上不可欠なユーザーが Google Cloud リソースに引き続きアクセスできるように、代替の認証方法を提供します。
バックアップ IdP を使用する: IdP の中断時にすべてのユーザーが Google Cloudリソースにアクセスできるようにするには、フォールバック IdP を維持します。
フォールバック IdP は、中断の影響をさらに最小限に抑えるのに役立ちますが、このオプションはすべての組織にとって費用対効果が高いとは限りません。
以降のセクションでは、推奨される手順とベスト プラクティスについて説明します。
緊急時アクセスを設定する
緊急アクセスは、Google Cloud リソースへの最後の手段としてのアクセスを可能にし、アクセス権を完全に失う可能性のある状況を防ぐことを目的としています。
緊急アクセス ユーザーには次のプロパティがあります。
- Cloud Identity アカウントまたは Google Workspace アカウントで作成するユーザーです。
- 特権管理者権限が付与されており、Cloud Identity、Google Workspace、Google Cloud リソースに影響する構成ミスを解決するのに十分なアクセス権がユーザーに提供されます。
- 組織内の特定の従業員に関連付けられておらず、通常のユーザー アカウントの Joiner、Mover、Leaver（JML）ライフサイクルから除外されます。
- SSO の対象外です。
以降のセクションでは、緊急アクセス ユーザーを管理して保護する際に従うことが推奨されるベスト プラクティスについて説明します。
環境ごとに緊急アクセス ユーザーを作成する
本番環境ワークロードをホストする Google Cloud 環境では、緊急アクセスが不可欠です。テストやステージングに使用される Google Cloud 環境では、アクセス権が失われると混乱が生じる可能性があります。
すべての Google Cloud 環境への継続的なアクセスを確保するには、Cloud Identity または Google Workspace で、環境ごとに緊急アクセス ユーザーを作成して維持します。
緊急アクセス冗長性を確保する
緊急アクセス ユーザーが 1 人だけの場合、単一障害点になります。このシナリオでは、セキュリティ キーの破損、パスワードの紛失、アカウントの停止によってアカウントへのアクセスが中断される可能性があります。このリスクを軽減するには、Cloud Identity アカウントまたは Google Workspace アカウントごとに複数の緊急アクセス ユーザーを作成します。
緊急アクセス ユーザーは非常に高い権限を持つため、作成しすぎないでください。ほとんどの組織では、Cloud Identity アカウントまたは Google Workspace アカウントごとに、緊急アクセス ユーザーを 2 人以上 5 人以下にすることをおすすめします。
緊急アクセス ユーザーに別の組織部門を使用する
緊急アクセス ユーザーには特別な構成が必要であり、他のユーザー アカウントで適用される JML ライフサイクルは適用されません。
緊急アクセス ユーザーを通常のユーザー アカウントと分離するには、緊急アクセス ユーザー専用の組織部門（OU）を使用します。別の組織部門を使用すると、緊急通報ユーザーにのみカスタム構成を適用できます。
2 段階認証プロセスに FIDO セキュリティ キーを使用する
2 段階認証プロセスに Fast IDentity Online（FIDO）セキュリティ キーを使用します。
緊急アクセス ユーザーは Cloud Identity アカウントまたは Google Workspace アカウントで特権の高いユーザーであるため、2 段階認証プロセスを使用してこれらのユーザーを保護する必要があります。
Cloud Identity と Google Workspace がサポートする 2 段階認証プロセスの方法のうち、FIDO セキュリティ キーを使用することをおすすめします。この方法では、フィッシング対策と強力なセキュリティが提供されます。緊急アクセス ユーザーが全員 2 段階認証プロセスに FIDO セキュリティ キーを使用するようにするには、次の操作を行います。
- 緊急アクセス ユーザーを含む組織部門で、認証方法としてセキュリティ キーのみを許可するように2 段階認証プロセスを設定します。
- 緊急アクセス ユーザー全員に対して 2 段階認証プロセスを有効にします。
- 緊急アクセス ユーザーごとに、2 つ以上の FIDO セキュリティ キーを登録します。
ユーザーごとに複数のキーを登録すると、セキュリティ キーの破損によるアクセス権の喪失のリスクを軽減できます。また、緊急時にユーザーが少なくとも 1 つの鍵にアクセスできる可能性も高まります。
複数の緊急アクセス ユーザーに同じセキュリティ キーのセットを使用しても問題ありません。ただし、緊急アクセス ユーザーごとに異なるセキュリティ キーを使用することをおすすめします。
物理的なセキュリティ制御を使用して認証情報とセキュリティ キーを保護する
緊急アクセス ユーザーの認証情報とセキュリティ キーを保存する場合は、強力な保護と緊急時の可用性のバランスを取る必要があります。
- 権限のないユーザーが緊急アクセス ユーザーの認証情報にアクセスできないようにします。緊急アクセス ユーザーは、緊急時にのみこれらの認証情報を使用する必要があります。
- 緊急時に承認された担当者が最小限の遅延で認証情報にアクセスできるようにします。
ソフトウェア ベースのパスワード マネージャーに依存しないことをおすすめします。代わりに、緊急アクセス ユーザーの認証情報とセキュリティ キーを保護するために、物理セキュリティ制御に依存することをおすすめします。
適用する物理セキュリティ コントロールを選択する際は、次の点を考慮してください。
- 可用性の向上:
- パスワードのコピーを、複数の物理的な場所に保管します（異なるオフィスにある複数のセキュリティ ボルトなど）。
- 緊急アクセス ユーザーごとに複数のセキュリティ キーを登録し、関連する各オフィスに 1 つのキーを保管します。
- セキュリティの強化: パスワードとセキュリティ キーを異なる場所に保管します。
パスワード ローテーションの自動化を避ける
緊急アクセス ユーザーのパスワード ローテーションを自動化することは、メリットがあるように思われるかもしれません。ただし、この自動化により、セキュリティ侵害のリスクが増大する可能性があります。緊急アクセス ユーザーには特権管理者の権限が付与されます。特権管理者ユーザーのパスワードをローテーションするには、自動化ツールまたはスクリプトにも特権管理者の権限が必要です。この要件により、ツールが攻撃者の魅力的な標的になる可能性があります。
全体的なセキュリティ体制を弱体化させないように、パスワードのローテーションに自動化を使用しないでください。
安全なパスワードを使用する
緊急アクセス ユーザーを保護するため、長く強力なパスワードを使用していることを確認してください。パスワードの複雑さの最低レベルを適用するには、前述のように専用の OU を使用し、パスワードの要件を実装します。
パスワードを手動でローテーションしない場合は、すべての緊急アクセス ユーザーに対してパスワードの有効期限を無効にします。
緊急アクセス ユーザーをアクセス ポリシーから除外する
緊急時には、コンテキストアウェア アクセス ポリシーによって、緊急アクセス ユーザーでも特定のリソースにアクセスできない状況が発生する可能性があります。このリスクを軽減するには、アクセス ポリシーのすべてのアクセスレベルから少なくとも 1 人の緊急アクセス ユーザーを除外します。
これらの例外により、緊急アクセス ユーザーの少なくとも 1 人がリソースに継続的にアクセスできるようになります。緊急時やコンテキストアウェア アクセス ポリシーの構成ミスが発生した場合でも、緊急アクセス ユーザーはアクセスを維持できます。
緊急アクセス ユーザー イベントに関するアラートを設定する
緊急イベント以外の緊急アクセス ユーザー アクティビティは、不審な動作を示している可能性があります。緊急アクセス ユーザーのアクティビティに関連するイベントについて通知を受け取るには、Google 管理コンソールでレポート ルールを作成します。レポートルールを作成するときに、次のような条件を設定できます。
- データソース: ユーザーのログイベント。
[Condition builder]（条件ビルダー）タブの属性: 属性と演算子を使用して、緊急アクセス ユーザーとイベントを含む組織部門のフィルタを作成します。
たとえば、属性と演算子を設定して、次のような条件文に似たフィルタを作成できます。
Actor organizational unit Is /Privileged AND (Event Is Successful login OR Event Is Failed login OR Event Is Account password change)しきい値: カウントが 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 を選択的に無効にすることもできます。組織部門の 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 に個別の SAML プロファイルを作成します。
- SSO プロファイルの割り当てを構成して、通常のオペレーション中にプライマリ IdP の SAML プロファイルのみを割り当てます。
- IdP の停止中にバックアップ IdP の SAML プロファイルを使用するように、SSO プロファイルの割り当てを変更します。個々の SAML プロファイルの設定は変更しないでください。
既存のオンプレミス IdP を使用する
バックアップとして機能する追加の IdP をプロビジョニングする必要はありません。代わりに、この目的で既存のオンプレミス IdP を使用できるかどうかを確認します。たとえば、組織で Active Directory を ID の信頼できるソースとして使用し、Active Directory フェデレーション サービス（AD FS）を SSO に使用している場合があります。このシナリオでは、AD FS をバックアップ IdP として使用できる場合があります。
この再利用アプローチは、コストとメンテナンス オーバーヘッドを制限するのに役立ちます。
必要な負荷を処理するようにバックアップ IdP を準備する
認証をバックアップ IdP に切り替える場合は、プライマリ IdP が通常処理するすべての認証リクエストを処理する必要があります。
バックアップ IdP をデプロイしてサイズ設定する場合は、予想されるリクエストの数が次の要因によって異なることに注意してください。
- Cloud Identity アカウントまたは Google Workspace アカウントのユーザー数。
- 構成されたGoogle Cloud セッションの長さ。
たとえば、セッションの長さが 8 ～ 24 時間の場合、従業員が勤務を開始する午前中に認証リクエストが急増する可能性があります。
フェイルオーバー手順を定期的にテストする
SSO フェイルオーバー プロセスが確実に機能するように、プロセスを定期的に検証する必要があります。フェイルオーバー手順をテストするときは、次の操作を行います。
- 1 つ以上の組織部門またはグループの SSO プロファイルの割り当てを手動で変更して、バックアップ IdP を使用します。
- バックアップ IdP を使用した SSO が想定どおりに動作することを確認します。
- 署名証明書が最新であることを確認します。
次のステップ
- 管理者アカウントのセキュリティに関するおすすめの方法を確認します。
- Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Johannes Passing | クラウド ソリューション アーキテクト
その他の寄稿者: Ido Flatow | クラウド ソリューション アーキテクト