篩選使用者內容

您可以根據使用者或使用者對文件的群組存取權來篩選使用者的搜尋結果。您可以使用使用者權杖、使用者 ID 或使用者屬性來篩選文件。 Amazon Kendra 也可以將使用者對應至其群組。您可以選擇用 AWS IAM Identity Center 作身分存放區/來源。

使用者前後關聯篩選是一種個人化搜尋，具有控制文件存取權的好處。例如，並非所有在公司入口網站中搜尋資訊的團隊都應該存取絕密的公司文件，這些文件也不應該與所有使用者相關。只有具備絕密文件存取權的特定使用者或專案團隊群組才能在搜尋結果中看到這些文件。

將文件編入索引時 Amazon Kendra，大多數文件都會擷取對應的存取控制清單 (ACL)。ACL 指定允許或拒絕存取文件的使用者名稱和群組名稱。沒有 ACL 的文件是公開文件。

Amazon Kendra 可以為大多數資料來源擷取與每個文件相關聯的使用者或群組資訊。例如，Quip 中的文檔可以包含具有文檔訪問權限的選擇用戶的「共享」列表。如果您使用 S3 儲存貯體做為資料來源，則為 ACL 提供 JSON 檔案，並將此檔案的 S3 路徑納入資料來源組態的一部分。如果您直接將文件新增至索引，您可以將主參與者物件中的 ACL 指定為 BatchPutDocumentAPI 中文件物件的一部分。

您可以使用 CreateAccessControlConfigurationAPI 重新設定現有文件層級存取控制，而無需再次編製所有文件的索引。例如，您的索引包含只有特定員工或使用者應存取的絕密公司文件。其中一位使用者離開公司或切換至應封鎖的小組，無法存取絕密文件。使用者仍然可以存取絕密文件，因為使用者可以存取您的文件先前已編製索引。您可以為具有拒絕存取權的使用者建立特定的存取控制組態。您可以稍後更新存取控制組態，以便在使用者返回公司並重新加入「絕密」小組的情況下允許存取。您可以在情況變更時重新設定文件的存取控制。

若要將存取控制設定套用至特定文件，請呼叫AccessControlConfigurationId包含在 Document 物件中的 BatchPutDocumentAPI。如果您使用 S3 儲存貯體做為資料來源，請使用資料來.metadata.json源更新AccessControlConfigurationId並同步處理資料來源。 Amazon Kendra 目前僅支援 S3 資料來源和使用 BatchPutDocument API 編製索引的文件的存取控制組態。

按用戶令牌過濾

當您查詢索引時，您可以使用使用者權杖，根據使用者或他們對文件的群組存取權來篩選搜尋結果。當您發出查詢時， Amazon Kendra 擷取和驗證 Token、提取並檢查使用者和群組資訊，然後執行查詢。傳回使用者可存取的所有文件 (包括公用文件)。如需詳細資訊，請參閱以權杖為基礎的使用者存取控制。

您可以在UserContext對象中提供用戶令牌，並在查詢 API 中傳遞此令牌。

以下說明如何包含使用者權杖。

response = kendra.query(
    QueryText = query,
    IndexId = index,
    UserToken = {
        Token = "token"
    })

您可以將使用者對應至群組。當您使用使用者內容篩選時，在您發出查詢時，不需要包含使用者所屬的所有群組。使用 PutPrincipalMappingAPI，您可以將使用者對應至其群組。如果您不想使用 PutPrincipalMapping API，則必須在發出查詢時提供使用者名稱和使用者所屬的所有群組。您也可以使用UserGroupResolutionConfiguration物件擷取 IAM 身分中心身分識別來源中群組和使用者的存取層級。

依使用者 ID 和群組篩選

當您查詢索引時，您可以使用使用者 ID 和群組，根據使用者或他們對文件的群組存取權來篩選搜尋結果。當您發出查詢時，請 Amazon Kendra 檢查使用者和群組資訊並執行查詢。系統會傳回與使用者可存取之查詢相關的所有文件 (包括公用文件)。

您也可以依使用者和群組可存取的資料來源篩選搜尋結果。如果群組與多個資料來源相關聯，但您只希望群組存取特定資料來源的文件，則指定資料來源非常有用。例如，組「研究」，「工程」和「銷售和營銷」都綁定到存儲在數據源匯流和 Salesforce 公司的文檔。不過，「銷售與行銷」團隊只需要存取儲存在 Salesforce 中的客戶相關文件。因此，當銷售和行銷使用者搜尋與客戶相關的文件時，他們可以在搜尋結果中看到 Salesforce 的文件。不從事銷售和行銷工作的使用者在搜尋結果中看不到 Salesforce 文件。

您可以在UserContext物件中提供使用者、群組和資料來源資訊，並在 Query API 中傳遞此資訊。使用者 ID、群組和資料來源清單應與您在 P rinci ence 物件中指定的名稱相符，以識別使用者、群組和資料來源。透過Principal物件，您可以將使用者、群組或資料來源新增至用於存取文件的允許清單或拒絕清單。

您必須提供下列其中一項：

• 使用者和群組資訊，以及 (選用) 資料來源資訊。

• 如果您使用 PutPrincipalMappingAPI 將使用者對應至群組和資料來源，則只有使用者資訊。您也可以使用UserGroupResolutionConfiguration物件擷取 IAM 身分中心身分識別來源中群組和使用者的存取層級。

如果查詢中未包含此資訊，則會 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 中傳遞此屬性。

下列範例會顯示根據使用者識別碼以及使用者所屬群組「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 的用戶和組信息經過身份驗證和授權。

每個資料來源都有使用者內容篩選的實作。以下部分描述了每個實現。

直接新增至索引的文件的使用者前後關聯篩選

當您使用 BatchPutDocumentAPI 直接將文件新增至索引時， Amazon Kendra 會從文件的AccessControlList欄位中取得使用者和群組資訊。您為文件提供存取控制清單 (ACL)，且 ACL 會隨您的文件一併擷取。

您可以在主參與者物件中指定 ACL 做為 BatchPutDocument API 中文件物件的一部分。您提供下列資訊：

• 使用者或群組應具有的存取權。你可以說ALLOW或DENY。

• 實體的類型。你可以說USER或GROUP。

• 使用者或群組的名稱。

您最多可以在AccessControlList欄位中新增 200 個項目。

常見問題集的使用者內容篩選

當您將常見問題集新增至索引時， Amazon Kendra 會從常見問題 JSON 檔案的AccessControlList物件/欄位取得使用者和群組資訊。您也可以使用具有自訂欄位或屬性的常見問題解答 CSV 檔案進行存取控制。

您提供下列資訊：

• 使用者或群組應具有的存取權。你可以說ALLOW或DENY。

• 實體的類型。你可以說USER或GROUP。

• 使用者或群組的名稱。

如需詳細資訊，請參閱 FAQ 檔案。

資料來源的使用者內容篩選

Amazon Kendra 也會從支援的資料來源連接器編目使用者和群組存取控制清單 (ACL) 資訊。這對於使用者前後關聯篩選非常有用，其中搜尋結果會根據使用者或他們對文件的群組存取權進行篩選。

主題

• Adobe 體驗管理員資料來源的使用者內容篩選
• 適用於露天資料來源的使用者內容篩選
• Aurora (MySQL) 資料來源的使用者內容篩選
• Aurora (PostgreSQL) 資料來源的使用者內容篩選
• Amazon FSx 資料來源的使用者內容篩選
• 資料庫資料來源的使用者內容篩選
• Amazon RDS (Microsoft SQL 伺服器) 資料來源的使用者內容篩選
• Amazon RDS (MySQL) 資料來源的使用者內容篩選
• Amazon RDS (Oracle) 資料來源的使用者內容篩選
• Amazon RDS (PostgreSQL) 資料來源的使用者內容篩選
• Amazon S3 資料來源的使用者內容篩選
• Amazon WorkDocs 資料來源的使用者內容篩選
• Box 資料來源的使用者內容篩選
• 匯流資料來源的使用者內容篩選
• Dropbox 資料來源的使用者上下文篩選
• Drupal 數據源的用戶上下文過濾
• GitHub 資料來源的使用者內容篩選
• Gmail 資料來源的使用者內容篩選
• Google 雲端硬碟資料來源的使用者內容篩選
• IBM DB2 資料來源的使用者內容篩選
• Jira 資料來源的使用者內容篩選
• Microsoft 交換資料來源的使用者內容篩選
• Microsoft OneDrive 資料來源的使用者內容篩選
• Microsoft OneDrive 2.0 資料來源的使用者內容篩選
• Microsoft SharePoint 資料來源的使用者內容篩選
• Microsoft SQL 伺服器資料來源的使用者內容篩選
• Microsoft 團隊資料來源的使用者內容篩選
• Microsoft Yammer 資料來源的使用者內容篩選
• MySQL 資料來源的使用者內容篩選
• Oracle 資料庫資料來源的使用者內容篩選
• PostgreSQL 資料來源的使用者內容篩選
• Quip 資料來源的使用者內容篩選
• Salesforce 資料來源的使用者內容篩選
• ServiceNow 資料來源的使用者內容篩選
• Slack 資料來源的使用者內容篩選
• Zendesk 資料來源的使用者內容篩選

Adobe 體驗管理員資料來源的使用者內容篩選

當您使用 Adobe 體驗管理員資料來源時， Amazon Kendra 會從 Adobe 體驗管理員實例取得使用者和群組資訊。

群組和使用者 ID 的對應方式如下：

• _group_ids群組 ID 存在於具有設定存取權限的 Adobe 體驗管理員內容中。它們會從 Adobe 體驗管理員中的群組名稱對應而來。

• _user_id使用者 ID 存在於具有設定存取權限的 Adobe 體驗管理員內容中。它們會從使用者電子郵件對應為 Adobe 體驗管理員中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

適用於露天資料來源的使用者內容篩選

當您使用 Alfresco 資料來源時， Amazon Kendra 會從 Alfresco 執行個體取得使用者和群組資訊。

群組和使用者 ID 的對應方式如下：

• _group_ids在有設置訪問權限的文件上，Alfresco 中存在組 ID。它們是從 Alfresco 中組的系統名稱（而不是顯示名稱）映射的。

• _user_id用戶 ID 存在於 Alfresco 中，存在於有設置訪問權限的文件上。它們從用戶電子郵件中映射為 Alfresco 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Aurora (MySQL) 資料來源的使用者內容篩選

當您使用 Aurora (MySQL) 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

Aurora (MySQL) 資料庫資料來源有以下限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Aurora (PostgreSQL) 資料來源的使用者內容篩選

當您使用 Aurora (PostgreSQL) 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

A Aurora (PostgreSQL) 資料庫資料來源具有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon FSx 資料來源的使用者內容篩選

使用資 Amazon FSx 料來源時， Amazon Kendra 會從 Amazon FSx 執行個體的目錄服務取得使用者和群組資訊。

群 Amazon FSx 組和使用者 ID 對應如下：

• _group_ids群組 ID 存在 Amazon FSx 於具有設定存取權限的檔案中。它們會從的目錄服務中的系統群組名稱對應 Amazon FSx。

• _user_id使用者 ID 存在 Amazon FSx 於具有設定存取權限的檔案中。它們會從的目錄服務中的系統使用者名稱對應 Amazon FSx。

您最多可以在AccessControlList欄位中新增 200 個項目。

資料庫資料來源的使用者內容篩選

當您使用資料庫資料來源時，例如 Amazon Aurora PostgreSQL， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在AclConfiguration物件中將此欄指定為 CreateDataSourceAPI 中DatabaseConfiguration物件的一部分。

資料庫資料來源有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon RDS (Microsoft SQL 伺服器) 資料來源的使用者內容篩選

當您使用 Amazon RDS (Microsoft SQL Server) 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

A Amazon RDS （Microsoft SQL 服務器）數據庫數據源具有以下限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon RDS (MySQL) 資料來源的使用者內容篩選

當您使用 Amazon RDS (MySQL) 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

Amazon RDS (MySQL) 資料庫資料來源有以下限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon RDS (Oracle) 資料來源的使用者內容篩選

使用 Amazon RDS (Oracle) 資料來源時， Amazon Kendra 會從來源表格中的欄取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

Amazon RDS (Oracle) 資料庫資料來源有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon RDS (PostgreSQL) 資料來源的使用者內容篩選

當您使用 Amazon RDS (PostgreSQL) 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

A Amazon RDS (PostgreSQL) 資料庫資料來源具有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Amazon S3 資料來源的使用者內容篩選

您可以使用與文件關聯的中繼 Amazon S3 資料檔案，將使用者前後關聯篩選新增至資料來源中的文件。您可以將資訊新增至 JSON 文件中的AccessControlList欄位。如需將中繼資料新增至從資 Amazon S3 料來源編製索引的文件的詳細資訊，請參閱 S3 文件中繼資料。

您提供三項資訊：

• 該實體應具有的訪問權限。你可以說ALLOW或DENY。

• 實體的類型。你可以說USER或GROUP。

• 實體的名稱。

您最多可以在AccessControlList欄位中新增 200 個項目。

Amazon WorkDocs 資料來源的使用者內容篩選

使用資 Amazon WorkDocs 料來源時， Amazon Kendra 會從 Amazon WorkDocs 執行個體取得使用者和群組資訊。

群 Amazon WorkDocs 組和使用者 ID 對應如下：

• _group_ids群組 ID 存在 Amazon WorkDocs 於具有設定存取權限的檔案中。它們會從中的群組名稱對應 Amazon WorkDocs。

• _user_id使用者 ID 存在 Amazon WorkDocs 於具有設定存取權限的檔案中。它們會從中的使用者名稱對應 Amazon WorkDocs。

您最多可以在AccessControlList欄位中新增 200 個項目。

Box 資料來源的使用者內容篩選

使用 Box 資料來源時， Amazon Kendra 會從 Box 執行個體取得使用者和群組資訊。

Box 群組和使用者 ID 的對應方式如下：

• _group_ids群組 ID 存在於 Box 中，存在於具有設定存取權限的檔案上。它們是從 Box 中的組的名稱映射的。

• _user_id在有設定存取權限的檔案上，使用者 ID 存在於 Box 中。它們從用戶電子郵件映射為 Box 中的用戶 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

匯流資料來源的使用者內容篩選

當您使用匯流資料來源時， Amazon Kendra 會從匯流執行個體取得使用者和群組資訊。

您可以使用空間權限頁面設定使用者和群組對空間的存取權限。對於頁面和博客，您可以使用限制頁面。如需有關空間權限的詳細資訊，請參閱 Confluence Support 網站上的空間權限概觀。如需有關頁面和部落格限制的詳細資訊，請參閱 Confluence Support 網站上的頁面限制。

匯流群組和使用者名稱的對應方式如下：

• _group_ids群組名稱會出現在有限制的空間、頁面和部落格上。它們是從匯流組的名稱映射的。群組名稱永遠是小寫。

• _user_id使用者名稱會出現在有限制的空間、頁面或部落格上。它們會根據您正在使用的匯流實例的類型進行映射。

  對於匯流連接器 v1.0

  • 伺服器-_user_id 是使用者名稱。用戶名總是小寫。

  • 雲端 — _user_id 是使用者的帳戶 ID。

  對於匯流連接器 v2.0

  • 伺服器-_user_id 是使用者名稱。用戶名總是小寫。

  • 雲端 — _user_id 是使用者的電子郵件 ID。

  重要

  若要讓使用者內容篩選正確運作您的 Confluence 連接器，您需要確定授與 Confluence 頁面存取權的使用者可見性設定為 [任何人]。如需詳細資訊，請參閱在 Atlassian 開發人員文件中設定電子郵件可見度。

您最多可以在AccessControlList欄位中新增 200 個項目。

Dropbox 資料來源的使用者上下文篩選

當您使用 Dropbox 資料來源時， Amazon Kendra 會從 Dropbox 執行個體取得使用者和群組資訊。

群組和使用者 ID 的對應方式如下：

• _group_ids— 群組 ID 存在於 Dropbox 中，存在於有設定存取權限的檔案上。它們是從 Dropbox 中的群組名稱對應而來。

• _user_id— 使用者 ID 存在於 Dropbox 中，存在於有設定存取權限的檔案上。它們從用戶的電子郵件中映射為 Dropbox 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Drupal 數據源的用戶上下文過濾

當你使用一個 Drupal 的數據源， Amazon Kendra 獲取從數據的用戶和組信息。

群組和使用者 ID 的對應方式如下：

• _group_ids— 組 ID 存在於 Drupal 中存在於有設置訪問權限的文件上。它們是從 Drupal 的組的名稱映射。

• _user_id— 用戶 ID 存在於 Drupal 中存在於有設置訪問權限的文件上。它們從用戶電子郵件中映射為 Drupal 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

GitHub 資料來源的使用者內容篩選

使用資 GitHub 料來源時， Amazon Kendra 會從執行個 GitHub 體取得使用者資訊。

GitHub 使用者 ID 的對應方式如下：

• _user_id使用者 ID 存在 GitHub 於具有設定存取權限的檔案中。它們會從使用者電子郵件中對應為中的 ID GitHub。

您最多可以在AccessControlList欄位中新增 200 個項目。

Gmail 資料來源的使用者內容篩選

當您使用 Gmail 資料來源時， Amazon Kendra 會從 Gmail 執行個體取得使用者資訊。

使用者 ID 對應如下：

• _user_id— 在有設置訪問權限的文件上，用戶 ID 存在於 Gmail 中。它們從用戶電子郵件中映射為 Gmail 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Google 雲端硬碟資料來源的使用者內容篩選

Google 工作區雲端硬碟資料來源會傳回 Google 雲端硬碟使用者和群組的使用者和群組資訊。群組和網域成員資格會對應至索_group_ids引欄位。Google 雲端硬碟使用者名稱會對應至_user_id欄位。

當您在 Query API 中提供一或多個使用者電子郵件地址時，只會傳回與這些電子郵件地址共用的文件。下列AttributeFilter參數只會傳回與「[e-mail]」共用的文件。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_user_id", 
                   "Value": {
                       "StringValue": "[e-mail]"
                   }
               }
           }

如果您在查詢中提供一或多個群組電子郵件地址，則只會傳回與群組共用的文件。下列AttributeFilter參數只會傳回與「[e-mail]」群組共用的文件。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_group_ids", 
                   "Value": {
                       "StringListValue": ["[e-mail]"]
                   }
               }
           }

如果您在查詢中提供網域，則會傳回與該網域共用的所有文件。下列AttributeFilter參數會傳回與「example.com」網域共用的文件。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_group_ids", 
                   "Value": {
                       "StringListValue": ["example.com"]
                   }
               }
           }

您最多可以在AccessControlList欄位中新增 200 個項目。

IBM DB2 資料來源的使用者內容篩選

當您使用 IBM DB2 資料來源時， Amazon Kendra 會從來源表格中的欄取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

IBM DB2 資料庫資料來源具有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Jira 資料來源的使用者內容篩選

使用 Jira 資料來源時， Amazon Kendra 會從 Jira 執行個體取得使用者和群組資訊。

Jira 使用者 ID 的對應方式如下：

• _user_id在有設定存取權限的檔案上，使用者 ID 存在於 Jira 中。它們從用戶電子郵件中映射為 Jira 中的用戶 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Microsoft 交換資料來源的使用者內容篩選

當您使用 Microsoft 交換資料來源時， Amazon Kendra 會從 Microsoft Exchange 執行個體取得使用者資訊。

Microsoft 交易所使用者識別碼對應如下：

• _user_id使用者識別碼存在於 Microsoft Exchange 權限中，可供使用者存取特定內容。它們是從用戶名映射為在 Microsoft 交易所的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Microsoft OneDrive 資料來源的使用者內容篩選

Amazon Kendra 當 Microsoft 索引網站上的文件 OneDrive 時，會從 Microsoft 擷取使用者和群組資訊。使用者和群組資訊取自主控的基礎 Microsoft SharePoint 網站 OneDrive。

當您使用使用 OneDrive 者或群組篩選搜尋結果時，請依照下列方式計算 ID：

1. 取得網站名稱。例如：https://host.onmicrosoft.com/sites/siteName.

2. 取站點名稱的 MD5 哈希值。例如 430a6b90503eef95c89295c8999c7981。

3. 透過將 MD5 雜湊與垂直列 (|) 和 ID 連接，以建立使用者電子郵件或群組 ID。例如，如果群組名稱是 "localGroupName"，則群組識別碼會是：

   "430a6b90503eef95c89295c8999c7981 | localGroupName"

   注意

   在垂直列前後加入空格。垂直條用於localGroupName與它的 MD5 哈希標識。

   使用者名稱「[e-mail]」的使用者識別碼如下：

   "430a6b90503eef95c89295c8999c7981 | [e-mail]"

當您呼叫查詢 API 時，將使用者_user_id或群組 ID Amazon Kendra 做為或_group_id屬性傳送至。例如，使用群組篩選搜尋結果的 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 2.0 資料來源的使用者內容篩選

Microsoft OneDrive 2.0 資料來源會從 OneDrive 存取控制清單 (ACL) 實體傳回區段和頁面資訊。 Amazon Kendra 使用 OneDrive 承租人網域連線至 OneDrive 執行個體，然後可以根據使用者或群組對區段和檔案名稱的存取權限篩選搜尋結果。

對於標準物件，_user_id和的使_group_id用方式如下：

• _user_id— 您的 Microsoft OneDrive 用戶電子郵件 ID 被映射到該_user_id字段。

• _group_id— 您的 Microsoft OneDrive 群組電子郵件已對應至_group_id欄位。

您最多可以在AccessControlList欄位中新增 200 個項目。

Microsoft SharePoint 資料來源的使用者內容篩選

Amazon Kendra 當 Microsoft 索引網站文件 SharePoint 時，會從 Microsoft 擷取使用者和群組資訊。若要根據使用者或群組存取權篩選搜尋結果，請在呼叫 Query API 時提供使用者和群組資訊。

若要使用使用者名稱進行篩選，請使用使用者的電子郵件地址。例如，[e-mail]。

當您使用 SharePoint 群組篩選搜尋結果時，請依照下列方式計算群組 ID：

對於本地團體

1. 取得網站名稱。例如：https://host.onmicrosoft.com/sites/siteName.

2. 採取站點名稱的 SHA256 哈希值。例如 430a6b90503eef95c89295c8999c7981。

3. 透過將 SHA256 雜湊與垂直列 (|) 和群組名稱相連，以建立群組識別碼。例如，如果群組名稱是 "localGroupName"，則群組識別碼會是：

   "430a6b90503eef95c89295c8999c7981 | localGroupName"

   注意

   在垂直列前後加入空格。垂直條用於localGroupName與它的 SHA256 哈希標識。

當您呼叫查詢 API 時，傳送群組識別碼 Amazon Kendra 做為_group_id屬性。例如， AWS CLI 命令看起來像這樣：

aws kendra  query \
                --index-id index ID  
                --query-text "query text" 
                --attribute-filter '{
                   "EqualsTo":{
                     "Key": "_group_id", 
                     "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"}
                  }}'

適用於廣告群組

1. 使用 AD 群組識別碼來設定搜尋結果的篩選。

當您呼叫查詢 API 時，傳送群組識別碼 Amazon Kendra 做為_group_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 伺服器資料來源的使用者內容篩選

當您使用 Microsoft SQL Server 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

Microsoft SQL 伺服器資料庫資料來源有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Microsoft 團隊資料來源的使用者內容篩選

Amazon Kendra 當它為文件編製索引時，會從 Microsoft 小組擷取使用者資訊。使用者資訊取自基礎 Microsoft 團隊執行個體。

您最多可以在AccessControlList欄位中新增 200 個項目。

Microsoft Yammer 資料來源的使用者內容篩選

Amazon Kendra 當它索引文檔時，會從 Microsoft Yammer 中檢索用戶信息。使用者和群組資訊取自基礎 Microsoft Yammer 執行個體。

Microsoft Yammer 使用者識別碼對應如下：

• _email_id— 映射到該_user_id字段的 Microsoft 電子郵件 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

MySQL 資料來源的使用者內容篩選

當您使用 MySQL 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

MySQL 資料庫資料來源有以下限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Oracle 資料庫資料來源的使用者內容篩選

當您使用「Oracle 資料庫」資料來源時， Amazon Kendra 會從來源表格中的資料欄取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

Oracle 資料庫資料來源有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

PostgreSQL 資料來源的使用者內容篩選

當您使用 PostgreSQL 資料來源時， Amazon Kendra 會從來源資料表中的資料行取得使用者和群組資訊。您可以在主控台中指定此欄，或使用TemplateConfiguration物件做為 CreateDataSourceAPI 的一部分。

PostgreSQL 資料庫資料來源具有下列限制：

• 您只能指定資料庫資料來源的允許清單。您無法指定拒絕清單。

• 您只能指定群組。您無法為允許清單指定個別使用者。

• 資料庫欄應該是包含以分號分隔的群組清單的字串。

Quip 資料來源的使用者內容篩選

當您使用 Quip 資料來源時， Amazon Kendra 會從 Quip 執行個體取得使用者資訊。

Quip 使用者識別碼的對應方式如下：

• _user_id在有設定存取權限的檔案上，使用者 ID 存在於 Quip 中。它們從用戶電子郵件映射為 Quip 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Salesforce 資料來源的使用者內容篩選

Salesforce 資料來源會從 Salesforce 存取控制清單 (ACL) 實體傳回使用者和群組資訊。您可以將使用者內容篩選套用至 Salesforce 標準物件和聊天程式摘要。Salesforce 知識文章無法使用使用者內容篩選。

如果您將任何 Salesforce 欄位對應至 Amazon Kendra 文件標題和文件內文欄位，Amazon Kendra 會在搜尋回應中使用文件標題和內文欄位中的資料。

對於標準物件，_user_id和的使_group_ids用方式如下：

• _user_idSalesforce 使用者的使用者名稱。

• _group_ids—

  • 銷售隊伍的名稱 Profile

  • 銷售隊伍的名稱 Group

  • 銷售隊伍的名稱 UserRole

  • 銷售隊伍的名稱 PermissionSet

對於喋喋不休的摘要，_user_id和的使_group_ids用方式如下：

• _user_idSalesforce 使用者的使用者名稱。只有當項目張貼在使用者的摘要中時才可用。

• _group_ids群組 ID 的使用方式如下。只有在動態消息項目張貼在聊天或協同作業群組時才可使用。

  • 聊天或協同作業群組的名稱。

  • 如果群組是公開的，PUBLIC:ALL.

您最多可以在AccessControlList欄位中新增 200 個項目。

ServiceNow 資料來源的使用者內容篩選

的使用者內容篩選 ServiceNow 僅支援 TemplateConfiguration API 和 ServiceNow 連接器 2.0 版。 ServiceNowConfigurationAPI 和 ServiceNow 連接器 1.0。不支持用戶上下文過濾。

使用資 ServiceNow 料來源時， Amazon Kendra 會從 ServiceNow 執行個體取得使用者和群組資訊。

群組和使用者 ID 的對應方式如下：

• _group_ids群組 ID 存在 ServiceNow 於具有設定存取權限的檔案中。它們是從中的角色名稱對應而sys_ids來 ServiceNow。

• _user_id使用者 ID 存在 ServiceNow 於具有設定存取權限的檔案中。它們會從使用者電子郵件中對應為中的 ID ServiceNow。

您最多可以在AccessControlList欄位中新增 200 個項目。

Slack 資料來源的使用者內容篩選

使用 Slack 資料來源時， Amazon Kendra 會從 Slack 執行個體取得使用者資訊。

Slack 使用者 ID 的對應方式如下：

• _user_idSlack 中有使用者 ID 存在於具有設定存取權限的訊息和通道上。它們會從使用者電子郵件對應為 Slack 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。

Zendesk 資料來源的使用者內容篩選

使用 Zendesk 資料來源時， Amazon Kendra 會從 Zendesk 執行個體取得使用者和群組資訊。

群組和使用者 ID 的對應方式如下：

• _group_ids群組 ID 存在於有設定存取權限的 Zendesk 票證和文章中。它們是從 Zendesk 中的群組名稱進行對映。

• _user_id群組 ID 存在於有設定存取權限的 Zendesk 票證和文章中。它們會從使用者電子郵件對應為 Zendesk 中的 ID。

您最多可以在AccessControlList欄位中新增 200 個項目。