翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ユーザーコンテキストでのフィルタリング
ユーザーまたはそのグループのドキュメントへのアクセスに基づいて、ユーザーの検索結果をフィルタリングできます。ユーザートークン、ユーザー ID、またはユーザー属性を使用して、ドキュメントをフィルタリングできます。 Amazon Kendra は、ユーザーをグループにマッピングすることもできます。ID ストア/ソースとして AWS IAM Identity Center を使用することを選択できます。
ユーザーコンテキストフィルタリングは、ドキュメントへのアクセスをコントロールできるという利点を持つ、パーソナライズされた検索の一種です。例えば、企業ポータルで情報を検索するすべてのチームが会社の極秘文書にアクセスする必要があるわけではなく、これらの文書がすべてのユーザーに関連しているわけでもありません。極秘文書へのアクセス許可を与えられた特定のユーザーまたはチームグループのみが、検索結果でこれらの文書を参照できます。
ドキュメントが にインデックス付けされると Amazon Kendra、対応するアクセスコントロールリスト (ACL) がほとんどのドキュメントに取り込まれます。ACL は、ドキュメントへのアクセスを許可または拒否するユーザー名とグループ名を指定します。ACL のないドキュメントはパブリックドキュメントです。
Amazon Kendra は、ほとんどのデータソースについて、各ドキュメントに関連付けられたユーザーまたはグループの情報を抽出できます。例えば、Quip のドキュメントには、そのドキュメントへのアクセス許可を持つ特定のユーザーの「共有」リストを含めることができます。S3 バケットをデータソースとして使用する場合は、ACL 用の JSON ファイルを提供し、このファイルへの S3 パスをデータソース設定の一部として含めます。ドキュメントをインデックスに直接追加する場合は、プリンシパルオブジェクトの ACL を BatchPutDocument API のドキュメントオブジェクトの一部として指定します。
CreateAccessControlConfiguration API を使用して、すべてのドキュメントのインデックスを再度作成することなく、既存のドキュメントレベルのアクセスコントロールを再設定できます。例えば、インデックスには、特定の従業員またはユーザーだけがアクセスできる会社の極秘文書が含まれています。これらのユーザーのうちの 1 人が会社を退職したり、極秘文書へのアクセスをブロックすべきチームに異動したりします。文書が前にインデックスが作成されたときにアクセス許可を持っていたため、ユーザーは引き続き極秘文書にアクセスできます。アクセスを拒否するユーザーに対して、特定のアクセスコントロール設定を作成できます。ユーザーが会社に戻って「極秘」チームに再び加わった場合にアクセスを許可するように、後でアクセスコントロール設定を更新できます。状況の変化に応じて、ドキュメントのアクセスコントロールを再設定できます。
アクセスコントロール設定を特定のドキュメントに適用するには、ドキュメントオブジェクトAccessControlConfigurationId
に含まれる を使用して BatchPutDocument API https://docs.aws.amazon.com/kendra/latest/APIReference/API_Document.htmlを呼び出します。S3 バケットをデータソースとして使用する場合は、 を .metadata.json
で更新AccessControlConfigurationId
し、データソースを同期します。 Amazon Kendra は現在、 BatchPutDocument
API を使用してインデックス作成された S3 データソースとドキュメントのアクセスコントロール設定のみをサポートしています。
ユーザートークンによるフィルタリング
インデックスをクエリする際、ユーザートークンを使用して、ユーザーまたはそのグループのドキュメントへのアクセスに基づいて、検索結果をフィルタリングできます。クエリを発行すると、 はトークンを Amazon Kendra 抽出して検証し、ユーザーとグループの情報をプルしてチェックし、クエリを実行します。パブリックドキュメントを含め、ユーザーがアクセスできるすべてのドキュメントが返されます。詳細については、「Token-based user access control」を参照してください。
UserContext オブジェクトでユーザートークンを指定し、これをクエリ API で渡します。
次に、ユーザートークンを含める方法を示します。
response = kendra.query( QueryText = query, IndexId = index, UserToken = { Token = "
token
" })
ユーザーをグループにマッピングできます。ユーザーコンテキストフィルタリングを使用する場合、クエリを発行するときに、ユーザーが属しているグループをすべて含める必要はありません。PutPrincipalMapping API を使用すると、ユーザーをグループにマッピングできます。PutPrincipalMapping
API を使用しない場合は、クエリを発行するときに、ユーザー名とユーザーが属するすべてのグループを指定する必要があります。UserGroupResolutionConfiguration オブジェクトを使用して、IAM Identity Center アイデンティティソースのグループとユーザーのアクセスレベルを取得することもできます。
ユーザー ID とグループによるフィルタリング
インデックスをクエリする際、ユーザー ID およびグループを使用して、ユーザーまたはそのグループのドキュメントへのアクセスに基づいて、検索結果をフィルタリングできます。クエリを発行すると、 はユーザーとグループの情報 Amazon Kendra をチェックし、クエリを実行します。パブリックドキュメントを含め、ユーザーがアクセスできるクエリに関連するすべてのドキュメントが返されます。
また、ユーザーおよびグループがアクセスできるデータソースで検索結果をフィルタリングできます。データソースの指定は、グループが複数のデータソースに関連付けられていても、特定のデータソースのドキュメントにのみアクセスできるようにする場合に便利です。例えば、「リサーチ」、「エンジニアリング」、および「セールスおよびマーケティング」のグループはすべて、Confluence および Salesforce のデータソースに保存されている企業のドキュメントに関連付けられています。ただし、「セールスおよびマーケティング」チームでは、Salesforce に保存されている顧客関連ドキュメントへのアクセスのみが必要です。そのため、営業やマーケティングに携わるユーザーが顧客関連のドキュメントを検索すると、その結果に Salesforce のドキュメントが表示されます。営業およびマーケティングで作業していないユーザーには、検索結果に Salesforce ドキュメントは表示されません。
UserContext オブジェクトでユーザー、グループ、データソースの情報を指定し、これをクエリ API に渡します。ユーザー ID、およびグループおよびデータソースのリストは、プリンシパルオブジェクトで指定した名前と一致する必要があり、ユーザー、グループ、およびデータソースを識別します。Principal
オブジェクトを使用すると、ドキュメントにアクセスするための許可リストまたは拒否リストに、ユーザー、グループ、またはデータソースを追加できます。
次のいずれかを提供する必要があります。
-
ユーザーとグループの情報、および (オプション) データソース情報。
-
PutPrincipalMapping API を使用してユーザーをグループとデータソースにマッピングする場合、ユーザー情報のみ。UserGroupResolutionConfiguration オブジェクトを使用して、IAM Identity Center アイデンティティソースのグループとユーザーのアクセスレベルを取得することもできます。
この情報がクエリに含まれていない場合、 はすべてのドキュメント Amazon Kendra を返します。この情報を指定すると、ユーザー ID、グループ、およびデータソースが一致するドキュメントのみが返されます。
次に、ユーザー ID、グループ、およびデータソースを含める方法を示します。
response = kendra.query( QueryText = query, IndexId = index, UserId = { UserId = "
user1
" }, Groups = { Groups = ["Sales and Marketing
"] }, DataSourceGroups = { DataSourceGroups = [{"DataSourceId" : "SalesforceCustomerDocsGroup
", "GroupId": "Sales and Marketing
"}] })
ユーザー属性でフィルタリングする
インデックスをクエリする際、組み込み属性の _user_id
および _group_id
を使用して、ユーザーおよびそのグループのドキュメントへのアクセスに基づいて、検索結果をフィルタリングできます。最大 100 個のグループ識別子を設定できます。クエリを発行すると、 はユーザーとグループの情報 Amazon Kendra をチェックし、クエリを実行します。パブリックドキュメントを含め、ユーザーがアクセスできるクエリに関連するすべてのドキュメントが返されます。
AttributeFilter オブジェクトにユーザー属性とグループ属性を指定し、これをクエリ API に渡します。
次の例は、ユーザー ID とユーザーが属するグループ「HR」および「IT」に基づいてクエリレスポンスをフィルタリングするリクエストを示しています。このクエリは、許可リストにユーザー、または「HR」または「IT」のグループを含むすべてのドキュメントを返します。ユーザーまたはいずれかのグループがドキュメントの拒否リストに含まれている場合、ドキュメントは返されません。
response = kendra.query( QueryText = query, IndexId = index, AttributeFilter = { "OrAllFilters": [ { "EqualsTo": { "Key": "_user_id", "Value": { "StringValue": "user1" } } }, { "EqualsTo": { "Key": "_group_ids", "Value": { "StringListValue": ["HR", "IT"] } } } ] } )
グループにアクセスできるデータソースは、Principal
オブジェクトにアクセスできます。
注記
ユーザーコンテキストフィルタリングは、コンテンツの認証または認可コントロールではありません。Query
API に送信されたユーザーおよびグループに対するユーザー認証は行いません。Query
API に送信されたユーザーおよびグループの情報が認証および認可されるか否かは、アプリケーションによって異なります。
各データソースのユーザコンテキストフィルタリングの実装があります。以下のセクションでは、各実装について説明します。
インデックスに直接追加されたドキュメントのユーザーコンテキストフィルタリング
BatchPutDocument API を使用してドキュメントをインデックスに直接追加すると、 はドキュメントの AccessControlList
フィールドからユーザーおよびグループの情報 Amazon Kendra を取得します。ドキュメントのアクセスコントロールリスト (ACL) を指定し、その ACL をドキュメントに取り込みます。
ACL は、BatchPutDocument
API のドキュメントオブジェクトの一部として、プリンシパルオブジェクトに指定します。次の情報を指定します。
-
ユーザーまたはグループが持つ必要があるアクセス許可。
ALLOW
またはDENY
の返答が可能です。 -
エンティティのタイプ。
USER
またはGROUP
の返答が可能です。 -
ユーザーまたはグループの名前。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
よくある質問に対するユーザーコンテキストのフィルタリング
よくある質問をインデックスに追加すると、 はよくある質問 JSON ファイルのAccessControlList
オブジェクト/フィールドからユーザーおよびグループの情報 Amazon Kendra を取得します。アクセスコントロール用のカスタムフィールドまたは属性を含む FAQ CSV ファイルを使用することもできます。
次の情報を指定します。
-
ユーザーまたはグループが持つ必要があるアクセス許可。
ALLOW
またはDENY
の返答が可能です。 -
エンティティのタイプ。
USER
またはGROUP
の返答が可能です。 -
ユーザーまたはグループの名前。
詳細については、「FAQ files」を参照してください。
データソースのユーザーコンテキストフィルタリング
Amazon Kendra は、サポートされているデータソースコネクタからユーザーおよびグループのアクセスコントロールリスト (ACL) 情報をクロールします。これは、ドキュメントへのユーザーまたはグループのアクセス許可に基づいて検索結果をフィルタリングする場合の、ユーザーコンテキストフィルタリングの設定に役立ちます。
トピック
- Adobe Experience Manager データソースのユーザーコンテキストフィルタリング
- Alfresco データソースのユーザーコンテキストフィルタリング
- Aurora (MySQL ) データソースのユーザーコンテキストフィルタリング
- Aurora (PostgreSQL) データソースのユーザーコンテキストフィルタリング
- Amazon FSx データソースのユーザーコンテキストフィルタリング
- データベースデータソースのユーザーコンテキストフィルタリング
- Amazon RDS (Microsoft SQL Server) データソースのユーザーコンテキストフィルタリング
- Amazon RDS (MySQL ) データソースのユーザーコンテキストフィルタリング
- Amazon RDS (Oracle) データソースのユーザーコンテキストフィルタリング
- Amazon RDS (PostgreSQL) データソースのユーザーコンテキストフィルタリング
- Amazon S3 データソースのユーザーコンテキストフィルタリング
- Amazon WorkDocs データソースのユーザーコンテキストフィルタリング
- Box データソースのユーザーコンテキストフィルタリング
- Confluence データソースのユーザーコンテキストフィルタリング
- Dropbox データソースのユーザーコンテキストフィルタリング
- Drupal データソースのユーザーコンテキストフィルタリング
- GitHub データソースのユーザーコンテキストフィルタリング
- Gmail データソースのユーザーコンテキストフィルタリング
- Google Drive データソースのユーザーコンテキストフィルタリング
- IBM DB2 データソースのユーザーコンテキストフィルタリング
- Jira データソースのユーザーコンテキストフィルタリング
- Microsoft Exchange データソースのユーザーコンテキストフィルタリング
- Microsoft OneDrive データソースのユーザーコンテキストフィルタリング
- Microsoft OneDrive v2.0 データソースのユーザーコンテキストフィルタリング
- Microsoft SharePoint データソースのユーザーコンテキストフィルタリング
- Microsoft SQL Server データソースのユーザーコンテキストフィルタリング
- Microsoft Teams データソースのユーザーコンテキストフィルタリング
- Microsoft Yammer データソースのユーザーコンテキストフィルタリング
- MySQL データソースのユーザーコンテキストフィルタリング
- Oracle Database データソースのユーザーコンテキストフィルタリング
- PostgreSQL データソースのユーザーコンテキストフィルタリング
- Quip データソースのユーザーコンテキストフィルタリング
- Salesforce データソースのユーザーコンテキストフィルタリング
- ServiceNow データソースのユーザーコンテキストフィルタリング
- Slack データソースのユーザーコンテキストフィルタリング
- Zendesk データソースのユーザーコンテキストフィルタリング
Adobe Experience Manager データソースのユーザーコンテキストフィルタリング
Adobe Experience Manager データソースを使用すると、 は Adobe Experience Manager インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、アクセス許可が設定されている Adobe Experience Manager コンテンツに存在します。これらは、Adobe Experience Manager のグループの名前からマッピングされます。 -
_user_id
- ユーザー ID は、アクセス許可が設定されている Adobe Experience Manager コンテンツに存在します。これらは、Adobe Experience Manager のユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Alfresco データソースのユーザーコンテキストフィルタリング
Alfresco データソースを使用すると、 は Alfresco インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、Alfresco のアクセス許可が設定されているファイルに存在します。Alfresco のグループ (表示名ではない) のシステム名からマッピングされます。 -
_user_id
- ユーザー ID は、Alfresco のアクセス許可が設定されているファイルに存在します。これらは Alfresco の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Aurora (MySQL ) データソースのユーザーコンテキストフィルタリング
Aurora (MySQL ) データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Aurora (MySQL ) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Aurora (PostgreSQL) データソースのユーザーコンテキストフィルタリング
Aurora (PostgreSQL ) データソースを使用すると、 Amazon Kendra はソーステーブルの列からユーザーおよびグループ情報を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Aurora (PostgreSQL ) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon FSx データソースのユーザーコンテキストフィルタリング
Amazon FSx データソースを使用すると、 はインスタンスの Amazon FSx ディレクトリサービスからユーザーおよびグループ情報 Amazon Kendra を取得します。
Amazon FSx グループ ID とユーザー IDsは、次のようにマッピングされます。
-
_group_ids
- グループ ID は、 Amazon FSx のアクセス許可が設定されているファイルに存在します。これらは、 のディレクトリサービスのシステムグループ名からマッピングされます Amazon FSx。 -
_user_id
— ユーザー IDsは Amazon FSx 、アクセス許可が設定されたファイルに存在します。これらは、 のディレクトリサービスのシステムユーザー名からマッピングされます Amazon FSx。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
データベースデータソースのユーザーコンテキストフィルタリング
などのデータベースデータソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Aurora PostgreSQL Amazon Kendra を取得します。この列は、 CreateDataSource API の AclConfiguration オブジェクトの一部として DatabaseConfiguration オブジェクトに指定します。
データベースデータソースには以下の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon RDS (Microsoft SQL Server) データソースのユーザーコンテキストフィルタリング
Amazon RDS (Microsoft SQL Server) データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Amazon RDS (Microsoft SQL Server) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon RDS (MySQL ) データソースのユーザーコンテキストフィルタリング
Amazon RDS (MySQL ) データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Amazon RDS (MySQL ) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon RDS (Oracle) データソースのユーザーコンテキストフィルタリング
Amazon RDS (Oracle) データソースを使用すると、 Amazon Kendra はソーステーブルの列からユーザーおよびグループの情報を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Amazon RDS (Oracle) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon RDS (PostgreSQL) データソースのユーザーコンテキストフィルタリング
Amazon RDS (PostgreSQL ) データソースを使用すると、 Amazon Kendra はソーステーブルの列からユーザーおよびグループ情報を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Amazon RDS (PostgreSQL ) データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Amazon S3 データソースのユーザーコンテキストフィルタリング
ドキュメントに関連付けられたメタデータファイルを使用して、 Amazon S3 データソース内のドキュメントにユーザーコンテキストフィルタリングを追加します。情報を JSON ドキュメント内の AccessControlList
フィールドに追加します。 Amazon S3 データソースからインデックスが作成されたドキュメントにメタデータを追加する方法の詳細については、「S3 document metadata」を参照してください。
次の 3 つの情報を提供します。
-
エンティティが持つべきアクセス。
ALLOW
またはDENY
の返答が可能です。 -
エンティティのタイプ。
USER
またはGROUP
の返答が可能です。 -
エンティティの名前。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Amazon WorkDocs データソースのユーザーコンテキストフィルタリング
Amazon WorkDocs データソースを使用すると、 は Amazon WorkDocs インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
Amazon WorkDocs グループ ID とユーザー IDsは、次のようにマッピングされます。
-
_group_ids
— グループ IDsは、アクセス許可が設定されたファイルの Amazon WorkDocs に存在します。これらは、 のグループの名前からマッピングされます Amazon WorkDocs。 -
_user_id
- ユーザー IDsは Amazon WorkDocs 、アクセス許可が設定されているファイルに存在します。これらは のユーザー名からマッピングされます Amazon WorkDocs。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Box データソースのユーザーコンテキストフィルタリング
Box データソースを使用すると、 は Box インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
Box グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、Box のアクセス許可が設定されているファイルに存在します。これらは Box のグループの名前からマッピングされます。 -
_user_id
- ユーザー ID は、Box のアクセス許可が設定されているファイルに存在します。これらは Box のユーザー ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Confluence データソースのユーザーコンテキストフィルタリング
Confluence データソースを使用すると、 は Confluence インスタンスからユーザーとグループの情報 Amazon Kendra を取得します。
[スペースアクセス許可] ページを使用して、スペースへのユーザーおよびグループアクセスを構成します。ページとブログの場合は、[制限] ページを使用します。スペースのアクセス許可の詳細については、Confluence Support ウェブサイトのスペースアクセス許可の概要
Confluence グループ名とユーザー名は、次のようにマッピングされます。
-
_group_ids
- グループ名は、制限のあるスペース、ページ、ブログに存在します。これらは Confluence のグループの名前からマッピングされます。グループ名は常に小文字です。
-
_user_id
- ユーザー名は、制限のあるスペース、ページ、ブログに存在します。これらは、使用している Confluence インスタンスのタイプに応じてマッピングされます。Confluence Connector v1.0 向け
-
サーバー -
_user_id
はユーザー名です。ユーザーネームは常に小文字です。 -
クラウド -
_user_id
はユーザーのアカウント ID です。
Confluence Connector v2.0 向け
-
サーバー -
_user_id
はユーザー名です。ユーザーネームは常に小文字です。 -
クラウド -
_user_id
はユーザーの E メール ID です。
重要
Confluence コネクタでユーザーコンテキストフィルタリングを正しく機能させるには、Confluence ページへのアクセスを許可されたユーザーの可視性が [全員] に設定されていることを確認する必要があります。詳細については、Atlassian デベロッパードキュメントの「Set your email visibility
」を参照してください。 -
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Dropbox データソースのユーザーコンテキストフィルタリング
Dropbox データソースを使用すると、 は Dropbox インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、Dropbox のアクセス許可が設定されているファイルに存在します。これらは Dropbox のグループの名前からマッピングされます。 -
_user_id
- ユーザー ID は、Dropbox のアクセス許可が設定されているファイルに存在します。これらは Dropbox の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Drupal データソースのユーザーコンテキストフィルタリング
Drupal データソースを使用すると、 は Drupalinstance からユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、Drupal のアクセス許可が設定されているファイルに存在します。これらは Drupal のグループの名前からマッピングされます。 -
_user_id
- ユーザー ID は、Drupal のアクセス許可が設定されているファイルに存在します。これらは Drupal の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
GitHub データソースのユーザーコンテキストフィルタリング
GitHub データソースを使用すると、 は GitHub インスタンスからユーザー情報 Amazon Kendra を取得します。
GitHub ユーザー IDs次のようにマッピングされます。
-
_user_id
- ユーザー IDsは GitHub 、アクセス許可が設定されているファイルに存在します。これらは、 の IDsされます GitHub。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Gmail データソースのユーザーコンテキストフィルタリング
Gmail データソースを使用すると、 は Gmail インスタンスからユーザー情報 Amazon Kendra を取得します。
ユーザー ID は、次のようにマッピングされます。
-
_user_id
- ユーザー ID は、Gmail のアクセス許可が設定されているファイルに存在します。これらは Gmail の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Google Drive データソースのユーザーコンテキストフィルタリング
Google Workspace Drive データソースは、Google Drive のユーザーおよびグループのユーザー情報とグループ情報を返します。グループおよびドメインメンバーシップは、_group_ids
インデックスフィールドにマッピングされます。Google Drive のユーザー名は、_user_id
フィールドにマッピングされます。
Query
API で 1 つ以上のユーザーの E メールアドレスを指定する場合、それらの E メールアドレスと共有されているドキュメントのみが返されます。以下の AttributeFilter
パラメータは、「martha@example.com」と共有されているドキュメントのみを返します。
"AttributeFilter": { "EqualsTo":{ "Key": "_user_id", "Value": { "StringValue": "martha@example.com" } } }
クエリで 1 つ以上のグループの E メールアドレスを指定すると、グループと共有されているドキュメントのみが返されます。以下の AttributeFilter
パラメータは、「hr@example.com」グループと共有されているドキュメントのみを返します。
"AttributeFilter": { "EqualsTo":{ "Key": "_group_ids", "Value": { "StringListValue": ["hr@example.com"] } } }
クエリでドメインを指定すると、ドメインで共有されているすべてのドキュメントが返されます。以下の AttributeFilter
パラメータは、「example.com」ドメインと共有されているドキュメントのみを返します。
"AttributeFilter": { "EqualsTo":{ "Key": "_group_ids", "Value": { "StringListValue": ["example.com"] } } }
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
IBM DB2 データソースのユーザーコンテキストフィルタリング
IBM DB2 データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
IBM DB2 データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Jira データソースのユーザーコンテキストフィルタリング
Jira データソースを使用すると、 は Jira インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
Jira ユーザー ID は、次のようにマッピングされます。
-
_user_id
- ユーザー ID は、Jira のアクセス許可が設定されているファイルに存在します。これらは Jira のユーザー ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft Exchange データソースのユーザーコンテキストフィルタリング
Microsoft Exchange データソースを使用すると、 は Microsoft Exchange インスタンスからユーザー情報 Amazon Kendra を取得します。
Microsoft Exchange ユーザー IDs、次のようにマッピングされます。
-
_user_id
— ユーザー IDs、ユーザーが特定のコンテンツにアクセスするための Microsoft Exchange アクセス許可に存在します。これらは、Microsoft Exchange の IDsされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft OneDrive データソースのユーザーコンテキストフィルタリング
Amazon Kendra は、サイト上のドキュメントのインデックス OneDrive を作成するときに、Microsoft からユーザーおよびグループ情報を取得します。ユーザーおよびグループの情報は、 をホストする基盤となる Microsoft SharePoint サイトから取得されます OneDrive。
検索結果のフィルタリングに OneDrive ユーザーまたはグループを使用する場合は、次のように ID を計算します。
-
サイト名を取得します。例えば、
https://host.onmicrosoft.com/sites/siteName.
。 -
サイト名の MD5 ハッシュを取ります。例えば
430a6b90503eef95c89295c8999c7981
です。 -
MD5 ハッシュを縦棒 (|) と ID で連結して、ユーザーの E メールまたはグループ ID を作成します。例えば、グループ名が「」の場合localGroupName、グループ ID は次のようになります。
"
430a6b90503eef95c89295c8999c7981 | localGroupName
"注記
垂直バーの前後にスペースを含めます。垂直バーは、MD5 ハッシュ
localGroupName
で を識別するために使用されます。ユーザー名が「someone@host.onmicrosoft.com」の場合、ユーザー ID は次のようになります。
"
430a6b90503eef95c89295c8999c7981 | someone@host.onmicrosoft.com
"
クエリ API を呼び出すときに、ユーザーまたはグループ ID を _user_id
または _group_id
属性 Amazon Kendra として に送信します。例えば、グループを使用して検索結果をフィルタリングする AWS CLI コマンドは次のようになります。
aws kendra query \ --index-id
index ID
--query-text "query text
" --attribute-filter '{ "EqualsTo":{ "Key": "_group_id", "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"} }}'
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft OneDrive v2.0 データソースのユーザーコンテキストフィルタリング
Microsoft OneDrive v2.0 データソースは、 OneDrive アクセスコントロールリスト (ACL) エンティティからセクションとページ情報を返します。 は OneDrive テナントドメイン Amazon Kendra を使用して OneDrive インスタンスに接続し、ユーザーまたはグループのセクションとファイル名へのアクセスに基づいて検索結果をフィルタリングできます。
標準オブジェクトについては、_user_id
および _group_id
が次のように使用されます。
-
_user_id
— Microsoft OneDrive ユーザーの E メール ID は_user_id
フィールドにマッピングされます。 -
_group_id
— Microsoft OneDrive グループの E メールは_group_id
フィールドにマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft SharePoint データソースのユーザーコンテキストフィルタリング
Amazon Kendra は、サイトドキュメントのインデックス SharePoint を作成するときに、Microsoft からユーザーおよびグループ情報を取得します。ユーザーまたはグループのアクセスに基づいて検索結果をフィルタリングするには、Query
API を呼び出すときにユーザーおよびグループの情報を指定します。
ユーザー名を使用してフィルタリングするには、ユーザーの E メールアドレスを使用します。例えば、johnstiles@example.com。
検索結果のフィルタリングに SharePoint グループを使用する場合は、グループ ID を次のように計算します。
ローカルグループ用
-
サイト名を取得します。例えば、
https://host.onmicrosoft.com/sites/siteName.
。 -
サイト名の SHA256 ハッシュを取ります。例えば
430a6b90503eef95c89295c8999c7981
です。 -
SHA256 ハッシュを縦棒 (|) と ID で連結して、グループ ID を作成します。例えば、グループ名が「」の場合localGroupName、グループ ID は次のようになります。
"
430a6b90503eef95c89295c8999c7981 | localGroupName
"注記
垂直バーの前後にスペースを含めます。垂直バーは、SHA256 ハッシュ
localGroupName
で を識別するために使用されます。
クエリ API を呼び出すときに、_group_id
属性 Amazon Kendra としてグループ ID を に送信します。例えば、 AWS CLI コマンドは次のようになります。
aws kendra query \ --index-id
index ID
--query-text "query text
" --attribute-filter '{ "EqualsTo":{ "Key": "_group_id", "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"} }}'
AD グループ用
-
AD グループ ID を使用して、検索結果のフィルタリングを設定します。
クエリ API を呼び出すときに、_group_id
属性 Amazon Kendra としてグループ ID を に送信します。例えば、 AWS CLI コマンドは次のようになります。
aws kendra query \ --index-id
index ID
--query-text "query text
" --attribute-filter '{ "EqualsTo":{ "Key": "_group_id", "Value": {"StringValue": "AD group"} }}'
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft SQL Server データソースのユーザーコンテキストフィルタリング
Microsoft SQL Server データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Microsoft SQL Server データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Microsoft Teams データソースのユーザーコンテキストフィルタリング
Amazon Kendra は、ドキュメントのインデックス作成時に Microsoft Teams からユーザー情報を取得します。ユーザー情報は、基盤となる Microsoft Teams インスタンスから取得されます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Microsoft Yammer データソースのユーザーコンテキストフィルタリング
Amazon Kendra は、ドキュメントのインデックス作成時に Microsoft Yammer からユーザー情報を取得します。ユーザーおよびグループの情報は、基盤となる Microsoft Yammer インスタンスから取得されます。
Microsoft Yammer ユーザー ID は、次のようにマッピングされます。
-
_email_id
—_user_id
フィールドにマッピングされた Microsoft E メール ID。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
MySQL データソースのユーザーコンテキストフィルタリング
MySQL データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
MySQL データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Oracle Database データソースのユーザーコンテキストフィルタリング
Oracle Database データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
Oracle Database データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
PostgreSQL データソースのユーザーコンテキストフィルタリング
PostgreSQL データソースを使用すると、 はソーステーブルの列からユーザーおよびグループの情報 Amazon Kendra を取得します。この列は、コンソールで指定するか、 CreateDataSource API の一部として TemplateConfiguration オブジェクトを使用します。
PostgreSQL データベースデータソースには、次の制限があります。
-
データベースデータソースの許可リストのみを指定できます。拒否リストを指定することはできません。
-
グループのみを指定できます。許可リストに個別のユーザーを指定することはできません。
-
データベース列は、セミコロンで区切られたグループのリストを含む文字列である必要があります。
Quip データソースのユーザーコンテキストフィルタリング
Quip データソースを使用すると、 は Quip インスタンスからユーザー情報 Amazon Kendra を取得します。
Quip ユーザー ID は、次のようにマッピングされます。
-
_user_id
- ユーザー ID は、Quip のアクセス許可が設定されているファイルに存在します。これらは Quip の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Salesforce データソースのユーザーコンテキストフィルタリング
Salesforce データソースは、Salesforce アクセスコントロールリスト (ACL) エンティティからユーザーおよびグループ情報を返します。Salesforce 標準オブジェクトおよび Chatter フィードにユーザーコンテキストフィルタリングを適用できます。ユーザーコンテキストフィルタリングは、Salesforce ナレッジ記事では使用できません。
Salesforce フィールドを Amazon Kendra ドキュメントタイトルとドキュメント本文フィールドにマッピングすると、Amazon Kendra は検索レスポンスでドキュメントタイトルと本文フィールドのデータを使用します。
標準オブジェクトについては、_user_id
および _group_ids
が次のように使用されます。
-
_user_id
- Salesforce ユーザーのユーザー名。 -
_group_ids
—-
Salesforce
Profile
の名前 -
Salesforce
Group
の名前 -
Salesforce
UserRole
の名前 -
Salesforce
PermissionSet
の名前
-
Chatter フィードの場合、_user_id
および _group_ids
は次のように使用されます。
-
_user_id
- Salesforce ユーザーのユーザー名。項目がユーザーのフィードに投稿されている場合にのみ使用できます。 -
_group_ids
- グループ ID は、次のように使用されます。フィードフィードが Chatter またはコラボレーショングループに投稿されている場合にのみ使用できます。-
Chatter グループまたはコラボレーショングループの名前。
-
グループが公開されている場合、
PUBLIC:ALL
。
-
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
ServiceNow データソースのユーザーコンテキストフィルタリング
のユーザーコンテキストフィルタリング ServiceNow は、 TemplateConfiguration API および ServiceNow Connector v2.0 でのみサポートされています。 ServiceNowConfiguration API および ServiceNow Connector v1.0。 はユーザーコンテキストフィルタリングをサポートしていません。
ServiceNow データソースを使用すると、 は ServiceNow インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ IDsは ServiceNow 、アクセス許可が設定されたファイルに存在します。これらは、 の のロール名からマッピングsys_ids
されます ServiceNow。 -
_user_id
- ユーザー IDsは ServiceNow 、アクセス許可が設定されているファイルに存在します。これらは、 の IDsされます ServiceNow。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Slack データソースのユーザーコンテキストフィルタリング
Slack データソースを使用すると、 は Slack インスタンスからユーザー情報 Amazon Kendra を取得します。
Slack ユーザー ID は、次のようにマッピングされます。
-
_user_id
- ユーザー ID は、アクセス許可が設定されている Slack のメッセージとチャネルに存在します。これらは Slack の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。
Zendesk データソースのユーザーコンテキストフィルタリング
Zendesk データソースを使用すると、 は Zendesk インスタンスからユーザーおよびグループ情報 Amazon Kendra を取得します。
グループ ID とユーザー ID は、次のようにマッピングされます。
-
_group_ids
- グループ ID は、アクセス許可が設定されている Zendesk のチケットおよび記事に存在します。これらは Zendesk のグループの名前からマッピングされます。 -
_user_id
- グループ ID は、アクセス許可が設定されている Zendesk のチケットおよび記事に存在します。これらは Zendesk の ID としてユーザーの E メールからマッピングされます。
AccessControlList
フィールドでは最大 200 個のエントリを追加できます。