このセクションでは、Cloud Identity を使用して、従業員が Google Cloud サービスにアクセスするために使用する ID を管理する方法について説明します。
信頼できる情報源としての外部 ID プロバイダ
Cloud Identity アカウントを既存の ID プロバイダと連携することをおすすめします。連携により、既存のアカウント管理プロセスを Google Cloud やその他の Google サービスに適用できます。
既存の ID プロバイダがない場合は、Cloud Identity で直接ユーザー アカウントを作成できます。
次の図は、ID 連携とシングル サインオン（SSO）の概要を示しています。ID プロバイダの例として、オンプレミス環境にある Microsoft Active Directory を使用しています。
この図は、次のベスト プラクティスを示しています。
- ユーザー ID は、オンプレミス環境にあり Cloud Identity と連携している Active Directory ドメインで管理されます。Active Directory は、Google Cloud Directory Sync を使用して Cloud Identity に ID をプロビジョニングします。
- Google サービスにログインしようとするユーザーは、SAML によるシングル サインオンのための外部 ID プロバイダにリダイレクトされ、既存の認証情報を使用して認証を受けます。パスワードは Cloud Identity と同期されません。
次の表に、ID プロバイダの設定ガイダンスへのリンクを示します。
| ID プロバイダ | ガイダンス |
|---|---|
| Active Directory | |
| Microsoft Entra ID（旧 Azure AD） | |
| 他の外部 ID プロバイダ（Ping、Okta など） |
Titan セキュリティ キーなどのフィッシング耐性のあるメカニズムを使用して、ご利用の ID プロバイダで多要素認証を適用することを強くおすすめします。
このブループリントの Terraform コードでは Cloud Identity の推奨設定は自動化されていません。Terraform コードのデプロイに加えて構成する必要がある推奨のセキュリティ設定については、Cloud Identity の管理機能をご覧ください。
アクセス制御用のグループ
プリンシパルは、リソースへのアクセス権を付与できる ID です。プリンシパルの例としては、ユーザー用の Google アカウント、Google グループ、Google Workspace アカウント、Cloud Identity ドメイン、サービス アカウントが挙げられます。一部のサービスでは、Google アカウントで認証するすべてのユーザー、またはインターネット上のすべてのユーザーにアクセス権を付与することもできます。プリンシパルが Google Cloud サービスとやり取りするには、Identity and Access Management（IAM）でロールを付与する必要があります。
IAM ロールを大規模に管理するには、職務とアクセス要件に基づいてユーザーをグループに割り当ててから、そのグループに IAM ロールを付与することをおすすめします。既存 ID プロバイダのグループ作成とメンバー管理のためのプロセスを使用して、グループにユーザーを追加する必要があります。
IAM ロールを個々のユーザーに付与することはおすすめしません。個々の割り当てによってロールの管理と監査が複雑になる可能性があるためです。
このブループリントでは、基盤リソースへの閲覧専用アクセス権のグループとロールを構成します。基盤パイプラインを使用してブループリントのすべてのリソースをデプロイすること、およびパイプライン外の基盤リソースを変更するロールをユーザーに付与しないことをおすすめします。
次の表は、基盤リソースを表示するために、ブループリントによって構成されるグループを示したものです。
| 名前 | 説明 | ロール | スコープ |
|---|---|---|---|
grp-gcp-org-admin@example.com |
組織レベルで IAM ロールを付与できる高度な権限を持つ管理者。他のロールにもアクセスできます。この権限は、日常的な使用にはおすすめしません。 | 組織管理者 | 組織 |
grp-gcp-billing-admin@example.com |
Cloud 請求先アカウントを変更できる高度な権限を持つ管理者。この権限は、日常的な使用にはおすすめしません。 | 請求先アカウント管理者 | 組織 |
grp-gcp-billing-viewer@example.com |
すべてのプロジェクトの費用の確認と分析を担当するチーム。 | 請求先アカウント閲覧者 | 組織 |
| BigQuery ユーザー | 課金プロジェクト | ||
grp-gcp-audit-viewer@example.com |
セキュリティ関連のログの監査を担当するチーム。 | ロギング プロジェクト | |
grp-gcp-monitoring-users@example.com |
アプリケーションのパフォーマンス指標のモニタリングを担当するチーム。 | モニタリング閲覧者 | モニタリング プロジェクト |
grp-gcp-security-reviewer@example.com |
クラウド セキュリティの審査を担当するチーム。 | セキュリティ審査担当者 | 組織 |
grp-gcp-network-viewer@example.com |
ネットワーク構成の表示と維持管理を担当するチーム。 | Compute ネットワーク閲覧者 | 組織 |
grp-gcp-scc-admin@example.com |
Security Command Center の構成を担当するチーム。 | セキュリティ センター管理編集者 | 組織 |
grp-gcp-secrets-admin@example.com |
アプリケーションで使用される認証情報とその他のシークレットの管理、保存、監査を担当するチーム。 | Secret Manager 管理者 | シークレット プロジェクト |
grp-gcp-kms-admin@example.com |
コンプライアンス要件を満たすために暗号鍵管理の強制適用を担当するチーム。 | Cloud KMS 閲覧者 | kms プロジェクト |
基盤上に独自のワークロードを構築する場合は、追加のグループを作成し、各ワークロードのアクセス要件に基づいて IAM ロールを付与します。
基本ロール（オーナー、編集者、閲覧者など）ではなく、事前定義ロールを使用することを強くおすすめします。基本ロールは制限が過度に緩いため、セキュリティ リスクが生じるおそれがあります。オーナーと編集者のロールは権限昇格とラテラル ムーブメントを引き起こす可能性があり、閲覧者のロールにはすべてのデータを読み取る権限が含まれます。IAM ロールのベスト プラクティスについては、IAM を安全に使用するをご覧ください。
特権管理者アカウント
特権管理者アカウントを持つ Cloud Identity ユーザーは、組織の SSO 設定を迂回し、Cloud Identity に対して直接認証を行います。この例外は設計上のものであり、SSO の構成ミスや停止が発生した場合でも、特権管理者が Cloud Identity コンソールにアクセスできます。ただし、特権管理者アカウントの保護強化を検討する必要があります。
特権管理者アカウントを保護するため、Cloud Identity のセキュリティ キーで常に 2 段階認証プロセスを適用することをおすすめします。詳しくは、管理者アカウントのセキュリティに関するおすすめの方法をご覧ください。
一般ユーザー向けアカウントの問題
Google Cloud にオンボーディングする前に Cloud Identity または Google Workspace を使用しなかった場合は、組織の従業員がすでに一般ユーザー向けアカウントを使用している可能性があります。このアカウントは、Google マーケティング プラットフォームや YouTube などの他の Google サービスにアクセスするための企業メール ID と関連付けられています。一般ユーザー向けアカウントは、作成者が完全に所有、管理するアカウントです。これらのアカウントは組織の管理対象外であり、個人データと企業データの両方が含まれている可能性があるため、これらのアカウントを他の企業アカウントと統合する方法を決定する必要があります。
Google Cloud へのオンボーディングの一環として、既存の一般ユーザー向けユーザー アカウントを統合することをおすすめします。まだすべてのユーザー アカウントで Google Workspace を使用していない場合は、新しい一般ユーザー向けアカウントの作成をブロックすることをおすすめします。
Cloud Identity の管理機能
Cloud Identity には、ブループリントの Terraform コードでは自動化されないさまざまな管理機能があります。基盤を構築するプロセスの早い段階で、これらのベスト プラクティスの各セキュリティ管理機能を適用することをおすすめします。
| 管理機能 | 説明 |
|---|---|
| 2 段階認証プロセスを導入する | ユーザー アカウントは、フィッシング、ソーシャル エンジニアリング、パスワード スプレー、その他のさまざまな脅威によって侵害されることがあります。2 段階認証プロセスは、これらの脅威を軽減するのに役立ちます。 Titan セキュリティ キーやフィッシング耐性のある FIDO U2F（CTAP1）標準に遵守したその他のキーなどのフィッシング耐性のあるメカニズムを採用して、組織内のすべてのユーザー アカウントに 2 段階認証プロセスを適用することをおすすめします。 |
| Google Cloud サービスのセッション継続時間を設定する | デベロッパーのワークステーション上の永続的な OAuth トークンは、漏洩した場合にセキュリティ リスクとなるおそれがあります。セキュリティ キーを使用した 16 時間ごとの認証を要求する再認証ポリシーを設定することをおすすめします。 |
| Google サービスのセッション継続時間を設定する | （Google Workspace をご利用のお客様のみ） 他の Google サービス間で永続的なウェブ セッションを公開すると、セキュリティ上のリスクが生じることがあります。ウェブ セッションの最大継続時間を適用し、SSO プロバイダのセッション継続時間の設定に合わせることをおすすめします。 |
| Cloud Identity のデータを Google Cloud サービスと共有する | Google Workspace または Cloud Identity の管理アクティビティ監査ログは通常、Google Cloud 環境のログとは別に管理コンソールで管理および表示されます。これらのログには、ユーザーのログイン イベントなど、Google Cloud 環境に関連する情報が含まれています。 すべてのソースからのログを一元管理するために、Cloud Identity 監査ログを Google Cloud 環境と共有することをおすすめします。 |
| SSO 後の検証を設定する | このブループリントでは、外部 ID プロバイダで SSO を設定することを想定しています。 Google のログインリスク分析に基づいて、追加の制御レイヤを有効にすることをおすすめします。この設定を適用すると、あるユーザーのログインが疑わしいと Google が判断した場合に、リスクがあるものとして、ログイン時に追加の本人確認が表示されることがあります。 |
| 一般ユーザー向けアカウントの問題を解消する | ドメインの有効なメールアドレスを持っているものの、Google アカウントを持っていないユーザーは、管理対象外の一般ユーザー向けアカウントを申請できます。これらのアカウントには企業データが含まれている場合がありますが、アカウント ライフサイクル管理プロセスでは管理されません。 すべてのユーザー アカウントが管理対象アカウントであることを確認することをおすすめします。 |
| 特権管理者アカウントの復元を無効にする | 特権管理者アカウントの自己復元は、すべての新規ユーザーに対してデフォルトで無効になっています（既存のユーザーの場合、この設定がオンになっている場合があります）。この設定をオフにすると、スマートフォン、メールの不正使用、ソーシャル エンジニアリング攻撃によって、攻撃者が環境に対する特権管理者権限を取得することになるリスクを軽減できます。 特権管理者がアカウントにアクセスできなくなった場合に組織内の別の特権管理者に連絡できる内部プロセスを計画し、すべての特権管理者がサポートによる復元のプロセスに精通していることを確認します。 |
| ユーザーのパスワード要件を適用、監視する | ほとんどの場合、ユーザー パスワードは外部 ID プロバイダを介して管理されますが、特権管理者アカウントは SSO を迂回するため、Cloud Identity へのログインにはパスワードを使用する必要があります。パスワードを使用して Cloud Identity にログインするユーザー（特に特権管理者アカウント）について、パスワードの再利用を無効にし、パスワードの安全度をモニタリングします。 |
| グループを使用するための組織全体のポリシーを設定する | デフォルトでは、外部ユーザー アカウントを Cloud Identity のグループに追加できます。グループ オーナーが外部メンバーを追加できないように、共有設定を構成することをおすすめします。 この制限は、特権管理者アカウント、またはグループ管理者権限を持つ他の代理管理者には適用されないことに注意してください。ID プロバイダからの連携は管理者権限で実行されるため、グループ共有設定はこのグループ同期には適用されません。ID プロバイダと同期メカニズムの管理機能を確認して、ドメイン以外のメンバーがグループに追加されないようにするか、グループ制限を適用することをおすすめします。 |
次のステップ
- 組織構造に関するドキュメント（このシリーズの次のドキュメント）を読む。