ドメイン全体の委任のベスト プラクティス

管理者はドメイン全体の委任を使用して、エンドユーザーの同意を迂回して、内部アプリとサードパーティ製アプリにユーザーの Google Workspace データへのアクセスを許可できます。これを行うには、Google Cloud コンソールでサービス アカウントを作成し、ドメイン全体の権限を Google 管理コンソールでアカウントに委任します。管理コンソールで、サービス アカウントに限定的な API スコープを指定することもできます。ドメイン全体の委任について詳しくは、ドメイン全体の委任で API アクセスを制御するをご覧ください。

サービス アカウントの管理と保護

Identity and Access Management（IAM）は、サービス アカウントを使用してアクセスを制限し、権限昇格と否認防止の脅威から保護するためのガイドラインを提供します。ガイドラインを確認するには、サービス アカウントの使用に関するベスト プラクティスをご覧ください。

このガイドに記載されているすべての推奨事項は、ドメイン全体の委任を使用するサービス アカウントを保護するためのものですが、いくつかの重要なプラクティスは次のとおりです。

	代わりに、サービス アカウントへの直接アクセスまたは OAuth 同意を使用してください サービス アカウントまたは OAuth 同意を使用してタスクを直接完了できる場合は、ドメイン全体の委任を使用しないでください。 ドメイン全体の委任の使用が不可避である場合は、サービス アカウントで使用できる一連の OAuth スコープを制限します。OAuth スコープによってサービス アカウントがなりすませるユーザーが制限されることはありませんが、サービス アカウントがアクセスできるユーザーデータの種類は制限されます。 ドメイン全体の委任を使用しないようにする
	サービス アカウント キーの作成とアップロードを制限する 組織のポリシーを使用して、ドメイン全体の委任があるサービス アカウントの鍵の作成とアップロードを制限します。これにより、サービス アカウント キーによるサービス アカウントの権限借用が制限されます。 ユーザーがサービス アカウント キーを作成またはアップロードすることを許可しない
	デフォルトのサービス アカウントに対するロールの自動付与を無効にする デフォルトで作成されるサービス アカウントには編集者のロールが付与され、Google Cloud プロジェクト内のすべてのリソースの読み取りと変更が許可されます。デフォルトのサービス アカウントに対するロールの自動付与を無効にすると、編集者のロールは自動的には付与されず、悪意のあるユーザーによって簡単に悪用されないようにすることができます。 デフォルトのサービス アカウントへの自動的なロール付与を使用しない
	ラテラル ムーブメントを制限する ラテラル ムーブメントとは、あるプロジェクトのサービス アカウントが別のプロジェクトのサービス アカウントの権限を借用することです。その結果、リソースへの意図しないアクセスが発生する可能性があります。「ラテラル ムーブメントの分析情報」を使用して、なりすましによるラテラル ムーブメントを検出して制限します。 ラテラル ムーブメントの分析情報を使用してラテラル ムーブメントを制限する
	ドメイン全体の委任を使用してサービス アカウントへのアクセスを制限する サービス アカウントにユーザーよりも多くの権限が付与されている場合は、ユーザーにサービス アカウントの許可ポリシーの変更を許可しないでください。IAM ロールを使用して、ドメイン全体の委任が付与されたサービス アカウントへのアクセスを制限します。 ユーザーが自身よりも高い権限を付与されているサービス アカウントの許可ポリシーを変更できないようにする

インサイダー リスクからサービス アカウントを保護する

ドメイン全体の委任は、アプリが Google Workspace データにアクセスする際にユーザーの同意をバイパスする必要がある重要なビジネスケースがある場合にのみ使用してください。ユーザーの同意を得る OAuth などの代替手段を試すか、Marketplace アプリを使用してください。詳しくは、Google Workspace Marketplace をご覧ください。

ドメイン全体の委任権限を持つサービス アカウントをインサイダー リスクから保護するには、次のベスト プラクティスに従ってください。

	重要な権限にのみアクセス権を付与する ドメイン全体の委任を使用するサービス アカウントに、目的の機能を実行するために必要な権限のみが付与されていることを確認します。必須ではない OAuth スコープにはアクセス権を付与しないでください。
	専用の Google Cloud プロジェクトでサービス アカウントをホストする ドメイン全体の委任を使用するサービス アカウントが、専用の Google Cloud プロジェクトでホストされていることを確認します。これらのプロジェクトを他のビジネスニーズに使用しないでください。
	サービス アカウント キーを使用しない ドメイン全体の委任を行うために、サービス アカウント キーを使用する必要はありません。代わりに signJwt API を使用してください。 ドメイン全体の委任にサービス アカウント キーを使用しない
	ドメイン全体の委任があるプロジェクトへのアクセスを制限する ドメイン全体の委任を設定して、Google Cloud プロジェクトの編集権限を持つユーザーの数を最小限に抑えます。Cloud Asset Inventory API を使用すると、サービス アカウントにアクセスできるユーザーを把握できます。たとえば、Cloud Shell を使用して以下を実行します。 gcloud asset get-effective-iam-policy --scope=organizations/<ORG_ID> --names=//iam.googleapis.com/projects/<PROJECT_ID>/serviceAccounts/ <SERVICE_ACCOUNT_ID> ORG_ID: Google Cloud 組織 ID。詳細 PROJECT_ID: サービス アカウントが存在する Google Cloud プロジェクトの ID。詳細 SERVICE_ACCOUNT_ID: サービス アカウントの ID。ID は、管理コンソールのドメイン全体の委任ページの [クライアント ID] か、サービス アカウントのメールアドレスに表示されます。詳細 iam.serviceAccountTokenCreator や iam.serviceAccountKeyAdmin のオーナーと編集者などの権限や役割を探して、サービス アカウントに対する直接権限または継承権限を持つユーザーを把握します。 Google Cloud サービス アカウントにアクセスできるユーザーを理解する

関連トピック

• セキュリティ チェックリスト
• Cloud Shell
• API アクセスをドメイン全体の委任で制御する