このページでは、プロジェクトとドキュメントのアクセス制御を管理する方法の概要について説明します。
データアクセス制御の概要
データアクセス制御は、Document AI ウェアハウスの主要な機能です。データアクセス制御は、Document AI ウェアハウスのどのリソースに、誰がアクセスできるのか、またその人にどのレベルのアクセス権を持たせるのかを制御します。
Document AI Warehouse API は Google Cloud 上に構築されています。HTTPS は、インターネット経由での安全なデータ転送を保証するために使用されます。Document AI Warehouse API では、Google ID に基づいてサービスとユーザーデータを保護するために、認証と認可が適用されます。
Document AI Warehouse API は、ユーザー アカウントでの認証に OAuth2 を使用します。すべての API メソッドには、https://www.googleapis.com/auth/cloud-platform OAuth スコープが必要です。
Document AI ウェアハウスは、Cloud IAM に基づいて顧客データのアクセス制御を適用します。Document AI ウェアハウスでは、さまざまなユーザーがサービスに保存されているデータにアクセスするのを制限するために、一連のロールと関連する権限を定義します。詳細については、IAM のロールと権限をご覧ください。
サービス アカウントを使用して基本的なアクセス制御を実施する
Document AI Warehouse API にアクセスするために必要な権限が付与されたサービス アカウントが必要です。クイックスタート ガイドの「 Google Cloud コンソールを使用してプロビジョニングする」の手順を行うと、Document AI Warehouse 管理者ロールを持つサービス アカウントが自動的にプロビジョニングされます。
アクセス制御モード
Document AI ウェアハウスには、次の 3 つのアクセス制御モードがあります。
- ユニバーサル アクセス: ドキュメント レベルのアクセス制御なし
- 独自の ID サービスを使用したドキュメント レベルのアクセス制御
- Cloud Identity を使用したドキュメント レベルのアクセス制御
ユーザーは、プロビジョニング プロセスでアクセスモードのいずれかを選択する必要があります。以降のセクションでは、3 つのアクセス制御モードの違いと、各モードを有効にする方法について説明します。
ユニバーサル アクセス
ユニバーサル アクセス制御を使用すると、Identity and Access Management(IAM)のみを使用して権限を管理できます。IAM は、認証された ID を持つプロジェクトのすべてのドキュメントに同じ権限を適用します。
このモードでは、クイックスタート ガイドでプロビジョニング手順を完了すると、ユーザーはサービス アカウントに関連付けられた権限を使用して、Document AI Warehouse サービスで選択した Google Cloudプロジェクトのすべてのドキュメントにアクセスできます。
このドキュメントの残りの部分では、ドキュメント レベルのアクセス制御について説明します。ユニバーサル アクセスを使用している場合は、このドキュメントの残りの部分をスキップしてください。
ドキュメント レベルのアクセス制御
Document AI ウェアハウスのユーザーは、次のいずれかを行うことができます。
- 独自の ID サービスを使用する
- リクエスト メタデータには、エンドユーザーとエンドユーザー メンバーシップ グループの両方が必要です。会社でユーザーの認証とユーザーが属するグループの特定を行う独自の方法がある場合は、このオプションを使用します。
- Cloud Identity を使用する
- Document AI ウェアハウスは、お客様の Cloud Identity からメンバーシップ グループを収集するため、リクエスト メタデータに必要なのはエンドユーザーのみです。カスタム ID サービスを使用する場合との違いは、ユーザーのグループ メンバーシップを管理するシステムが、社内システムではなく Cloud Identity であることです。
ドキュメント レベルのアクセスモードを使用する場合、いくつかの制限事項があります。
- ACL の メンバーとロールのみがサポートされています。IAM の条件は無視されます。
- カスタムロールは ACL でサポートされていません。
- Document AI Warehouse はエンドユーザーの認証情報を検証しません。Document AI Warehouse は、呼び出しが顧客からのものであることを確認するために、サービス アカウント認証情報のみを検証します。エンドユーザーの認証情報は、お客様側で確認する必要があります。
- アクセス制御を適用するには、リクエスト メタデータでエンドユーザー(Cloud Identity オプションを使用していない場合は、エンドユーザーがメンバーになっているすべてのグループ)を指定する必要があります。
- エンドユーザーのメンバーシップ グループの数は 100 未満である必要があります。
お客様独自の ID サービスを使用したドキュメント レベルのアクセス制御
このモードは、次のことを行う場合に選択できます。
- エンドユーザー(グループ)に、各ドキュメントへのアクセス権を個別に付与します。
- 独自の ID サービスを使用します。
このモードでは、IAM とアクセス制御リスト(ACL)を併用して権限を管理できます。Document AI ウェアハウスの各ドキュメントは、特定のドキュメント レベルの ACL で構成できます。認証と認可は次のように行われます。
- サービス アカウントの認証情報が認証され、サービスへのアクセスが承認されます。
- リクエスト メタデータに、エンドユーザーとエンドユーザーのメンバーシップ グループを含めます。エンドユーザーまたはエンドユーザーが所属するグループの少なくとも 1 つが、ドキュメントにアクセスする権限を持っている必要があります。
Document AI Warehouse は、上記のリストの条件が両方とも満たされている場合にのみ、リクエストされたドキュメントへのアクセス権を付与します。
API 呼び出しで提供された RequestMetadata の UserInfo(エンドユーザー ID とユーザー メンバーシップ グループ ID を含む)は、エンドユーザーがリクエストされたドキュメント リソースに対して対応するアクションを実行できるかどうかを検証するために使用されます。たとえば、GetDocument API で提供される UserInfo は、エンドユーザーがドキュメントを閲覧できるかどうかを検証するために使用されます。エンドユーザーまたはメンバーシップ グループのいずれかがドキュメントの閲覧を許可されている場合、エンドユーザーはドキュメントの閲覧を許可されます。
JSON 形式の RequestMetadata の例:
request_metadata: {
user_info: {
id: user:fake_user_id
group_ids: [
group:fake_group_id_1,
group:fake_group_id_2,
group:fake_group_id_3,
]
}
}このアクセス制御モードでは、クイックスタート ガイドの手順に加えて、Document AI ウェアハウスに API の送信を開始する前に、次の手順を行う必要があります。
- ディレクトリ サービス(Azure Active Directory や Okta など)から特定のエンドユーザーのグループ メンバーシップを取得します。
- アクセス制御を構成するの手順に沿って、デフォルトのプロジェクト ポリシーを設定します。作成後に特定のドキュメントのドキュメント レベルの ACL を設定することもできます。
上記の手順を完了すると、サービス アカウントを使用して、リクエスト本文の RequestMetadata セクションにエンドユーザーとグループ メンバーシップの情報を指定して、Document AI Warehouse に API 呼び出しを行う準備が整います。
このモードでは、エンドユーザーの認証と認可を行うためにプロキシをデプロイする必要があります。プロキシは、管理者ロールが付与されたサービス アカウントを使用してサービスにアクセスします。サービス アカウント キーは、プロキシでのみ使用されるように保護する必要があります。
Document AI ウェアハウス コンソールは、サービス アカウント キーを保存し、Google ID を介してエンドユーザーを認証し、リクエストを Document AI ウェアハウスに転送できるプロキシとして、すぐに使用できるソリューションです。
Cloud Identity を使用したドキュメント レベルのアクセス制御
独自の ID サービスを使用する代わりに、Cloud Identity を使用してプロセスを簡素化することもできます。
ユーザーとグループを一元管理するには、 Google Cloud お客様は Cloud Identity をゼロから設定するか、Google と他の ID プロバイダ(Active Directory、Azure Active Directory など)の間で ID を連携させることができます。
API 呼び出しで提供される RequestMetadata の UserInfo セクションは、エンドユーザーがリクエストされたドキュメント リソースに対して対応するアクションを実行できるかどうかを検証するために使用されます。Cloud Identity を使用すると、RequestMetadata で必要なのはエンドユーザー ID のみとなり、Document AI ウェアハウスは Cloud Identity サービスからメンバーシップ グループ情報を収集します。エンドユーザーまたはメンバーシップ グループのいずれかがドキュメントへのアクセスを許可されている場合、エンドユーザーはドキュメントにアクセスできます。
JSON 形式の RequestMetadata の例:
request_metadata: {
user_info: {
id: user:fake_user_id
}
}このアクセス制御モードでは、クイックスタート ガイドの手順に加えて、Document AI Warehouse にリクエストを送信する前に、次の手順を行う必要があります。
- エンドユーザーとグループ用に Cloud Identity と統合します。
- アクセス制御を構成するの手順に沿って、デフォルトのプロジェクト ポリシーを設定します。作成後に特定のドキュメントのドキュメント レベルの ACL を設定することもできます。
上記の手順を完了すると、サービス アカウントを使用して、リクエスト ボディの RequestMetadata セクションにエンドユーザー情報を含む Document AI Warehouse に API 呼び出しを行う準備が整います。
アクセス制御の構成
始める前に
始める前に、クイックスタート ページを完了していることを確認してください。
SetAcl と FetchAcl
新しいプロジェクトが作成された時点では、プロジェクト ACL は設定されていません。プロジェクト オーナーは、Document AI Warehouse SetAcl API を呼び出して、サービス アカウントを使用して projectOwner フィールドを true に設定することで、プロジェクトの事前定義されたロールを使用してデフォルトのプロジェクト ポリシーを設定できます。プロジェクト ポリシーのメンバーは、付与されたロールに応じて、プロジェクト内のすべてのドキュメントにアクセスできます。管理ユーザーまたはグループにアクセス権を付与するには、デフォルトのプロジェクト ポリシーを使用します。
次の表に、ドキュメントの各操作に必要なロールをまとめます。各ロールに付与される権限の詳細については、IAM のロールと権限をご覧ください。
サービス アカウントを使用して Document Schema API を呼び出すには、projects.locations.documentSchemas をご覧ください。
| Document API メソッド | 必要なロール |
|---|---|
CreateDocument |
roles/contentwarehouse.documentCreator |
UpdateDocument |
roles/contentwarehouse.documentEditor |
DeleteDocument SetACL |
roles/contentwarehouse.documentAdmin |
GetDocument FetchACL
SearchDocuments |
roles/contentwarehouse.documentViewer
|
CreateDocument
エンドユーザーまたはグループに作成者アクセス権が付与されていない場合は、付与します。
- [省略可] エンドユーザー管理者のメンバーシップ グループを顧客の ID サービスから取得します。Cloud Identity を使用しているお客様は、この手順をスキップできます。
- エンドユーザー管理者 [およびメンバーシップ グループ] をリクエスト メタデータに含めて、サービス アカウントを使用して
SetAclを呼び出すことで、プロジェクト レベルでエンドユーザー A(またはユーザー A がメンバーであるグループ)にroles/contentwarehouse.documentCreatorロールを付与します。エンドユーザーの管理者は、プロジェクト レベルで documentAdmin アクセス権を持っています。
ドキュメントを作成する:
- 省略可: エンドユーザー A のメンバーシップ グループを ID サービスから取得します。Cloud Identity を使用している場合は、この手順をスキップできます。
- リクエスト メタデータにエンドユーザー A [とメンバーシップ グループ] を指定して
CreateDocumentを呼び出し、サービス アカウントを使用してドキュメントを作成します。ドキュメントが作成されると、エンドユーザー A はデフォルトでドキュメントを表示および編集できます。お客様は、作成時にユーザーまたはグループにアクセス権を付与するデフォルト ポリシーを指定することもできます。たとえば、groupX にdocumentViewerアクセス権、groupY にdocumentEditorアクセス権、groupZ にdocumentAdminアクセス権を付与します。
GetDocument と FetchAcl
ドキュメントが作成されると、エンドユーザー A または groupX、groupY、groupZ のメンバーは GetDocument を呼び出してドキュメントを表示したり、FetchAcl を呼び出してドキュメントの ACL を表示したりできます。手順は次のとおりです。
- 省略可: エンドユーザー A のメンバーシップ グループを ID サービスから取得します。Cloud Identity を使用している場合は、この手順をスキップできます。
- リクエスト メタデータでエンドユーザー A(およびメンバーシップ グループ)を含むサービス アカウントを使用して、
GetDocumentまたはFetchAclを呼び出します。
B が groupX、groupY、groupZ のメンバーでない場合、エンドユーザー B からの通話は拒否されます。
UpdateDocument、DeleteDocument、SetAcl
ドキュメントの作成後、エンドユーザー A、groupY のメンバー、または groupZ のメンバーのみが UpdateDocument を呼び出してドキュメントを更新できます。エンドユーザー A または groupZ のメンバーのみが DeleteDocument を呼び出してドキュメントを削除したり、SetAcl を呼び出してドキュメントを他のエンドユーザーやグループと共有したりできます。手順は次のとおりです。
- 省略可: エンドユーザー A のメンバーシップ グループを ID サービスから取得します。Cloud Identity を使用している場合は、この手順をスキップできます。
- エンドユーザー A [およびメンバーシップ グループ] をリクエスト メタデータに含めて、サービス アカウントを使用して
UpdateDocument、DeleteDocument、またはSetAclを呼び出します。
groupX のメンバーはドキュメントに対する documentViewer アクセス権しか持っていないため、このメンバーからの呼び出しは拒否されます。
SearchDocuments
返されるドキュメントは、エンドユーザーに付与されたロールによって異なります。たとえば、検索クエリが空の場合、エンドユーザーがプロジェクト レベルで documentViewer アクセス権を持っていると、プロジェクト内のすべてのドキュメントが返されます。それ以外の場合、指定されたエンドユーザーに対して contentwarehouse.documents.get 権限を持つドキュメントのみが返されます。
SearchDocument API を呼び出すには、次の操作を行う必要があります。
- 省略可: エンドユーザー A のメンバーシップ グループを ID サービスから取得します。Cloud Identity を使用している場合は、この手順をスキップできます。
- リクエスト メタデータでエンドユーザー A(およびメンバーシップ グループ)のサービス アカウントを使用して
SearchDocumentを呼び出します。
Document Link API
| Document Link API メソッド | 必要なロール |
|---|---|
CreateDocumentLink
|
ソース:
roles/contentwarehouse.documentEditor
ターゲット: roles/contentwarehouse.documentViewer |
ListLinkedTargets ListLinkedSources |
roles/contentwarehouse.documentViewer
|
DeleteDocumentLink
|
ソース:
roles/contentwarehouse.documentEditor |
CreateDocumentLink
エンドユーザーが doc1 の contentwarehouse.documents.update 権限と doc2 の contentwarehouse.documents.get 権限を持っている場合、エンドユーザーはドキュメント doc1 とドキュメント doc2 をリンクできます。
ListLinkedTargets と ListLinkedSources
エンドユーザーは、contentwarehouse.documents.get 権限を持つターゲット ドキュメントまたはソース ドキュメントのみを一覧表示できます。
DeleteDocumentLink
エンドユーザーは、ソース ドキュメントに対する contentwarehouse.documents.update 権限を持っている場合、リンクを削除できます。