Filtrar por contexto de usuario - Amazon Kendra

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Filtrar por contexto de usuario

Puede filtrar los resultados de búsqueda de un usuario según el acceso del usuario o de su grupo a los documentos. Puede usar un token de usuario, un ID de usuario o un atributo de usuario para filtrar los documentos. Amazon Kendra también puede asignar los usuarios a sus grupos. Puede optar por utilizar AWS IAM Identity Center como origen o almacén de identidades.

El filtrado por contexto de usuario es un tipo de búsqueda personalizada con la ventaja de controlar el acceso a los documentos. Por ejemplo, no todos los equipos que buscan información en el portal corporativo deben acceder a los documentos de alto secreto de la empresa, ni estos documentos son relevantes para todos los usuarios. Solo los usuarios o grupos de equipos específicos que tengan acceso a documentos de alto secreto deberían ver estos documentos en sus resultados de búsqueda.

Cuando se indexa un documento Amazon Kendra, se incorpora la lista de control de acceso (ACL) correspondiente para la mayoría de los documentos. La ACL especifica a qué nombres de usuario y de grupo se les permite o deniega el acceso al documento. Los documentos sin una ACL son documentos públicos.

Amazon Kendra puede extraer la información de usuario o grupo asociada a cada documento para la mayoría de las fuentes de datos. Por ejemplo, un documento de Quip puede incluir una lista “compartida” de usuarios seleccionados que tienen acceso al documento. Si utiliza un bucket de S3 como origen de datos, debe proporcionar un archivo JSON para su ACL e incluir la ruta de S3 a este archivo como parte de la configuración del origen de datos. Si agrega documentos directamente a un índice, especifica la ACL en el objeto principal como parte del objeto de documento de la BatchPutDocumentAPI.

Puede usar la CreateAccessControlConfigurationAPI para volver a configurar su control de acceso a nivel de documento existente sin tener que volver a indexar todos los documentos. Por ejemplo, su índice contiene documentos empresariales de alto secreto a los que solo deben acceder determinados empleados o usuarios. Uno de estos usuarios deja la empresa o pasa a un equipo al que se le debería impedir el acceso a los documentos de alto secreto. El usuario sigue teniendo acceso a los documentos de alto secreto porque tenía acceso a ellos cuando los documentos estaban indexados anteriormente. Puede crear una configuración de control de acceso específica para el usuario con acceso denegado. Más adelante, puede actualizar la configuración de control de acceso para permitirle el acceso en caso de que el usuario regrese a la empresa y vuelva a unirse al equipo “de alto secreto”. Puede volver a configurar el control de acceso a sus documentos a medida que cambian las circunstancias.

Para aplicar tu configuración de control de acceso a determinados documentos, llamas a la BatchPutDocumentAPI con el objeto AccessControlConfigurationId incluido en el documento. Si utiliza un bucket de S3 como fuente de datos, lo actualiza .metadata.json con la fuente de datos AccessControlConfigurationId y la sincroniza. Amazon Kendra Actualmente, solo admite la configuración de control de acceso para las fuentes de datos y los documentos de S3 indexados mediante la BatchPutDocument API.

Filtrado por token de usuario

Al consultar un índice, puede usar un token de usuario para filtrar los resultados de búsqueda según el acceso del usuario o de su grupo a los documentos. Al realizar una consulta, Amazon Kendra extrae y valida el token, extrae y comprueba la información del usuario y del grupo y ejecuta la consulta. Se devuelven todos los documentos a los que el usuario tiene acceso, incluidos los documentos públicos. Para obtener más información, consulte Control de acceso de usuarios basado en tokens.

Debe proporcionar el token de usuario en el UserContextobjeto y pasarlo a la API de consultas.

El siguiente ejemplo muestra cómo incluir un token de usuario.

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

Puede asignar usuarios a grupos. Al utilizar el filtrado por contexto de usuario, no es necesario incluir todos los grupos a los que pertenece un usuario al realizar la consulta. Con la PutPrincipalMappingAPI, puedes asignar usuarios a sus grupos. Si no desea utilizar la API PutPrincipalMapping, debe proporcionar el nombre de usuario y todos los grupos a los que pertenece el usuario cuando realice una consulta. También puede obtener los niveles de acceso de los grupos y usuarios de la fuente de identidad de su centro de identidad de IAM mediante el UserGroupResolutionConfigurationobjeto.

Filtrado por ID de usuario y grupo

Al consultar un índice, puede usar el ID de usuario y el grupo para filtrar los resultados de búsqueda según el acceso del usuario o de su grupo a los documentos. Al realizar una consulta, Amazon Kendra comprueba la información del usuario y del grupo y ejecuta la consulta. Se devuelven todos los documentos relevantes para la consulta a los que el usuario tiene acceso, incluidos los documentos públicos.

También puede filtrar los resultados de búsqueda por los orígenes de datos a las que tienen acceso los usuarios y los grupos. Especificar un origen de datos resulta útil si un grupo está vinculado a varios orígenes de datos, pero solo desea que el grupo acceda a los documentos de un origen de datos determinado. Por ejemplo, pongamos que los grupos “Investigación”, “Ingeniería” y “Ventas y marketing” están todos vinculados a los documentos de la empresa almacenados en los orígenes de datos Confluence y Salesforce. Sin embargo, solo el equipo de “Ventas y marketing” necesita acceder a los documentos relacionados con los clientes almacenados en Salesforce. De este modo, cuando los usuarios de ventas y marketing busquen documentos relacionados con los clientes, podrán ver los documentos de Salesforce en sus resultados. Los usuarios que no trabajan en ventas y marketing no ven los documentos de Salesforce en sus resultados de búsqueda.

Debe proporcionar la información sobre el usuario, los grupos y las fuentes de datos en el UserContextobjeto y transferirla a la API de consultas. El ID de usuario y la lista de grupos y orígenes de datos deben coincidir con el nombre que especifique en el objeto Principal para identificar al usuario, los grupos y los orígenes de datos. Con el objeto Principal, puede añadir un usuario, un grupo o un origen de datos a una lista de permisos o de denegaciones para acceder a un documento.

Debe proporcionar uno de los siguientes datos:

  • Información de usuarios y grupos, e información (opcional) sobre los orígenes de datos.

  • Solo la información del usuario si asigna sus usuarios a grupos y fuentes de datos mediante la PutPrincipalMappingAPI. También puede obtener los niveles de acceso de los grupos y usuarios de la fuente de identidad de su centro de identidad de IAM mediante el UserGroupResolutionConfigurationobjeto.

Si esta información no está incluida en la consulta, Amazon Kendra devuelve todos los documentos. Si proporciona esta información, solo devolverá los documentos con los ID de usuario, grupos y orígenes de datos que coinciden.

El siguiente ejemplo muestra cómo incluir los ID de usuario, los grupos y los orígenes de datos.

response = kendra.query( QueryText = query, IndexId = index, UserId = { UserId = "user1" }, Groups = { Groups = ["Sales and Marketing"] }, DataSourceGroups = { DataSourceGroups = [{"DataSourceId" : "SalesforceCustomerDocsGroup", "GroupId": "Sales and Marketing"}] })

Filtrado por atributo de usuario

Al consultar un índice, puede usar los atributos integrados _user_id y _group_id para filtrar los resultados de búsqueda según el acceso del usuario y de su grupo a los documentos. Puede configurar hasta 100 identificadores de grupo. Al realizar una consulta, Amazon Kendra comprueba la información del usuario y del grupo y ejecuta la consulta. Se devuelven todos los documentos relevantes para la consulta a los que el usuario tiene acceso, incluidos los documentos públicos.

Debe proporcionar los atributos de usuario y grupo en el AttributeFilterobjeto y pasarlos a la API de consultas.

El siguiente ejemplo muestra una solicitud que filtra la respuesta a la consulta en función del ID de usuario y de los grupos “HR” e “IT” a los que pertenece el usuario. La consulta devolverá cualquier documento que contenga el usuario o los grupos “HR” o “IT” en su la lista de permitidos. Si el usuario o alguno de los grupos figuran en la lista de denegados de un documento, ese documento no se devolverá.

response = kendra.query( QueryText = query, IndexId = index, AttributeFilter = { "OrAllFilters": [ { "EqualsTo": { "Key": "_user_id", "Value": { "StringValue": "user1" } } }, { "EqualsTo": { "Key": "_group_ids", "Value": { "StringListValue": ["HR", "IT"] } } } ] } )

También puede especificar a qué origen de datos puede acceder un grupo en el objeto Principal.

nota

El filtrado por contexto de usuario no es un control de autenticación o autorización del contenido. No autentica a los usuarios ni a los grupos enviados a la API Query. Es responsabilidad de su aplicación garantizar que la información de usuarios y grupos enviada a la API Query esté autenticada y autorizada.

Existe una implementación del filtrado por contexto de usuario para cada origen de datos. En la siguiente sección se describe cada implementación.

Filtrado por contexto de usuario para los documentos añadidos directamente a un índice

Al añadir documentos directamente a un índice mediante la BatchPutDocumentAPI, Amazon Kendra obtiene información de usuarios y grupos del AccessControlList campo del documento. Debe proporcionar una lista de control de acceso (ACL) para los documentos y la ACL se incorpora con los documentos.

Debe especificar la ACL en el objeto Principal como parte del objeto Documento de la API BatchPutDocument. Debe proporcionar la siguiente información:

  • El acceso que debe tener el usuario o el grupo. Puede decir ALLOW o DENY.

  • El tipo de entidad. Puede decir USER o GROUP.

  • Nombre del usuario o grupo.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para las preguntas más frecuentes

Al añadir una pregunta frecuente a un índice, Amazon Kendra obtiene información sobre el usuario y el grupo del AccessControlList objeto o campo del archivo JSON de preguntas frecuentes. También puede usar un archivo CSV de preguntas frecuentes con campos o atributos personalizados para el control de acceso.

Debe proporcionar la siguiente información:

  • El acceso que debe tener el usuario o el grupo. Puede decir ALLOW o DENY.

  • El tipo de entidad. Puede decir USER o GROUP.

  • Nombre del usuario o grupo.

Para obtener más información, consulte Archivos de preguntas frecuentes.

Filtrado por contexto de usuario para los orígenes de datos

Amazon Kendra también rastrea la información de la lista de control de acceso (ACL) de usuarios y grupos desde los conectores de fuentes de datos compatibles. Esto resulta útil para el filtrado por contexto de usuario, en el que se filtran los resultados de búsqueda en función del acceso del usuario o de su grupo a los documentos.

Temas

Filtrado por contexto de usuario para los orígenes de datos de Adobe Experience Manager

Cuando utiliza una fuente de datos de Adobe Experience Manager, Amazon Kendra obtiene la información de usuario y grupo de la instancia de Adobe Experience Manager.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en el contenido de Adobe Experience Manager, donde hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos en Adobe Experience Manager.

  • _user_id: los ID de usuario existen en el contenido de Adobe Experience Manager, donde hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Adobe Experience Manager.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Alfresco

Cuando utiliza una fuente de datos de Alfresco, Amazon Kendra obtiene la información de usuario y grupo de la instancia de Alfresco.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en Alfresco en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de sistema de los grupos (no de los nombres de visualización) de Alfresco.

  • _user_id: los ID de usuario existen en Alfresco en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Alfresco.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado de contexto de usuario para fuentes de datos Aurora (MySQL)

Cuando utiliza una fuente de datos Aurora (MySQL), Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Aurora (MySQL) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Aurora (PostgreSQL)

Cuando utiliza una fuente de datos Aurora (PostgreSQL) Amazon Kendra , obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Aurora (PostgreSQL) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado del contexto de usuario para Amazon FSx las fuentes de datos

Cuando utiliza una fuente de Amazon FSx datos, Amazon Kendra obtiene información de usuarios y grupos del servicio de directorio de la Amazon FSx instancia.

Los ID de Amazon FSx grupo y usuario se mapean de la siguiente manera:

  • _group_ids: los ID de grupo existen en Amazon FSx en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos del sistema en el servicio de directorio de. Amazon FSx

  • _user_id—Los ID de usuario existen en los archivos Amazon FSx en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de usuario del sistema en el servicio de directorio de. Amazon FSx

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de bases de datos

Cuando utiliza una fuente de datos de base de datos, por ejemplo Amazon Aurora PostgreSQL, Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en el AclConfigurationobjeto como parte del DatabaseConfigurationobjeto de la CreateDataSourceAPI.

Un origen de datos de bases de datos tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para orígenes de datos de Amazon RDS (Microsoft SQL Server).

Cuando utiliza una fuente de datos Amazon RDS (Microsoft SQL Server), Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Amazon RDS (Microsoft SQL Server) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado de contexto de usuario para fuentes de datos Amazon RDS (MySQL)

Cuando utiliza una fuente de datos Amazon RDS (MySQL), Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Amazon RDS (MySQL) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado de contexto de usuario para fuentes de datos Amazon RDS (Oracle)

Cuando utiliza una fuente de datos Amazon RDS (Oracle), Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Amazon RDS (Oracle) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Amazon RDS (PostgreSQL)

Cuando utiliza una fuente de datos Amazon RDS (PostgreSQL) Amazon Kendra , obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Una fuente de datos de base de datos Amazon RDS (PostgreSQL) tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Amazon S3

El filtrado por contexto de usuario se añade a un documento de una fuente de Amazon S3 datos mediante un archivo de metadatos asociado al documento. Debe añadir la información al campo AccessControlList del documento JSON. Para obtener más información sobre cómo añadir metadatos a los documentos indexados desde un origen de datos de Amazon S3 , consulte Metadatos de documentos de S3.

Debe proporcionar tres datos:

  • El acceso que debe tener la entidad. Puede decir ALLOW o DENY.

  • El tipo de entidad. Puede decir USER o GROUP.

  • El nombre de la entidad.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado de contexto de usuario para fuentes Amazon WorkDocs de datos

Cuando utiliza una fuente de Amazon WorkDocs datos, Amazon Kendra obtiene información de usuarios y grupos de la Amazon WorkDocs instancia.

Los ID de Amazon WorkDocs grupo y usuario se mapean de la siguiente manera:

  • _group_ids—Los ID de grupo existen en los archivos Amazon WorkDocs en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos incluidos en ellos. Amazon WorkDocs

  • _user_id—Los ID de usuario existen en los archivos Amazon WorkDocs en los que hay permisos de acceso establecidos. Se mapean a partir de los nombres de usuario que aparecen en. Amazon WorkDocs

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Box

Cuando utiliza una fuente de datos de Box, Amazon Kendra obtiene información de usuarios y grupos de la instancia de Box.

Los ID de grupo y usuario de Box se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en Box en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos en Box.

  • _user_id: los ID de usuario existen en Box en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID de usuario en Box.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Confluence

Cuando utilizas una fuente de datos de Confluence, Amazon Kendra obtiene información de usuarios y grupos de la instancia de Confluence.

Debe configurar el acceso de los usuarios y grupos a los espacios mediante la página de permisos de los espacios. Para las páginas y los blogs, debe utilizar la página de restricciones. Para obtener más información sobre los permisos de espacio, consulte Información general de los permisos de espacio en el sitio web de soporte de Confluence. Para obtener más información sobre las restricciones de páginas y blogs, consulte Información general de las restricciones de espacio en el sitio web de soporte de Confluence.

Los nombres de grupo y usuario de Confluence se asignan de la siguiente manera:

  • _group_ids: los nombres de grupo están presentes en los espacios, páginas y blogs donde hay restricciones. Se asignan a partir del nombre del grupo en Confluence. Los nombres de grupo siempre están en minúscula.

  • _user_id: los nombres de usuario están presentes en el espacio, página o blog donde hay restricciones. Se asignan en función del tipo de instancia de Confluence que utilice.

    Para el conector de Confluence v1.0

    • Servidor: _user_id es el nombre de usuario. El nombre de usuario siempre está en minúscula.

    • Nube: _user_id es el ID de cuenta del usuario.

    Para el conector de Confluence v2.0

    • Servidor: _user_id es el nombre de usuario. El nombre de usuario siempre está en minúscula.

    • Nube: _user_id es el ID de correo electrónico del usuario.

    importante

    Para que el filtrado por contexto de usuario funcione correctamente en su conector de Confluence, debe asegurarse de que la visibilidad de un usuario al que se le ha concedido acceso a una página de Confluence esté configurada como Cualquiera. Para obtener más información, consulte Configurar la visibilidad del correo electrónico en la documentación para desarrolladores de Atlassian.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Dropbox

Cuando utilizas una fuente de datos de Dropbox, Amazon Kendra obtiene la información del usuario y del grupo de la instancia de Dropbox.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en Dropbox en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos en Dropbox.

  • _user_id: los ID de usuario existen en Dropbox en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Dropbox.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Drupal

Cuando utilizas una fuente de datos de Drupal, Amazon Kendra obtiene la información del usuario y del grupo de la instancia de Drupal.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en Drupal en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos en Drupal.

  • _user_id: los ID de usuario existen en Drupal en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Drupal.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado del contexto de usuario para las fuentes de datos GitHub

Cuando utiliza una fuente de GitHub datos, Amazon Kendra obtiene información de usuario de la GitHub instancia.

Los ID GitHub de usuario se mapean de la siguiente manera:

  • _user_id—Los ID de usuario existen en los archivos GitHub en los que hay permisos de acceso establecidos. Se mapean a partir de los correos electrónicos de los usuarios como identificadores. GitHub

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Gmail

Cuando utilizas una fuente de datos de Gmail, Amazon Kendra obtiene la información del usuario de la instancia de Gmail.

Los ID de usuario se asignan de la siguiente manera:

  • _user_id: los ID de usuario existen en Gmail en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Gmail.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Google Drive

Un origen de datos de Google Workspace Drive devuelve información de usuarios y grupos para usuarios y grupos de Google Drive. La pertenencia a grupos y dominios se asigna al campo del índice _group_ids. El nombre de usuario de Google Drive se asigna al campo _user_id.

Si proporciona una o más direcciones de correo electrónico de usuario en la API Query, solo se devuelven los documentos que se hayan compartido con esas direcciones de correo electrónico. El siguiente parámetro AttributeFilter solo devuelve los documentos compartidos con “martha@example.com”.

"AttributeFilter": { "EqualsTo":{ "Key": "_user_id", "Value": { "StringValue": "martha@example.com" } } }

Si proporciona una o más direcciones de correo electrónico de grupos en la consulta, solo se devolverán los documentos compartidos con los grupos. El siguiente parámetro AttributeFilter solo devuelve los documentos compartidos con el grupo “hr@example.com”.

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

Si proporciona el dominio en la consulta, se devolverán todos los documentos compartidos con el dominio. El siguiente parámetro AttributeFilter devuelve los documentos compartidos con el dominio “example.com”.

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

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de IBM DB2

Cuando utiliza una fuente de datos de IBM DB2, Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Un origen de datos de una base de datos de IBM DB2 tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Jira

Cuando utilizas una fuente de datos de Jira, Amazon Kendra obtiene información de usuarios y grupos de la instancia de Jira.

Los ID de usuario de Jira se asignan de la siguiente manera:

  • _user_id: los ID de usuario existen en Jira en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID de usuario en Jira.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para orígenes de datos de Microsoft Exchange

Cuando utiliza una fuente de datos de Microsoft Exchange, Amazon Kendra obtiene la información del usuario de la instancia de Microsoft Exchange.

Los ID de usuario de Microsoft Exchange se asignan de la siguiente manera:

  • _user_id—Los ID de usuario existen en los permisos de Microsoft Exchange para que los usuarios accedan a determinado contenido. Se asignan a partir de los nombres de usuario como identificadores en Microsoft Exchange.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado de contexto de usuario para fuentes OneDrive de datos de Microsoft

Amazon Kendra recupera información de usuarios y grupos de Microsoft OneDrive cuando indexa los documentos del sitio. La información de usuario y grupo se toma del SharePoint sitio de Microsoft subyacente que aloja OneDrive.

Cuando utilice un OneDrive usuario o un grupo para filtrar los resultados de la búsqueda, calcule el identificador de la siguiente manera:

  1. Obtenga el nombre del sitio. Por ejemplo, https://host.onmicrosoft.com/sites/siteName.

  2. Tome el hash MD5 del nombre del sitio. Por ejemplo, 430a6b90503eef95c89295c8999c7981.

  3. Cree el ID del correo electrónico del usuario o el ID del grupo concatenando el hash MD5 con una barra vertical (|) y el ID. Por ejemplo, si el nombre de un grupo es "localGroupName«, el ID del grupo sería:

    "430a6b90503eef95c89295c8999c7981 | localGroupName"

    nota

    Incluye un espacio antes y después de la barra vertical. La barra vertical se utiliza para identificarse localGroupName con su hash MD5.

    Para el nombre de usuario “someone@host.onmicrosoft.com”, el ID de usuario sería el siguiente:

    "430a6b90503eef95c89295c8999c7981 | someone@host.onmicrosoft.com"

Envía el ID de usuario o grupo Amazon Kendra como _group_id atributo _user_id o cuando llames a la API de consulta. Por ejemplo, el AWS CLI comando que usa un grupo para filtrar los resultados de la búsqueda tiene el siguiente aspecto:

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

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado de contexto de usuario para fuentes de datos de Microsoft OneDrive v2.0

Una fuente de datos de Microsoft OneDrive v2.0 devuelve información de secciones y páginas de las entidades de la lista de control de OneDrive acceso (ACL). Amazon Kendra usa el dominio OneDrive arrendatario para conectarse a la OneDrive instancia y, a continuación, puede filtrar los resultados de la búsqueda en función del acceso de los usuarios o grupos a las secciones y los nombres de los archivos.

En el caso de los objetos estándar, los _user_id y _group_id se utilizan de la siguiente manera:

  • _user_id— Su ID OneDrive de correo electrónico de usuario de Microsoft está asignado al _user_id campo.

  • _group_id— El correo electrónico de su OneDrive grupo de Microsoft está asignado al _group_id campo.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado de contexto de usuario para fuentes SharePoint de datos de Microsoft

Amazon Kendra recupera la información de usuarios y grupos de Microsoft SharePoint cuando indexa los documentos del sitio. Para filtrar los resultados de la búsqueda en función del acceso de los usuarios o grupos, proporciona información sobre los usuarios y los grupos cuando llames a la Query API.

Para filtrar mediante un nombre de usuario, utilice la dirección de correo electrónico del usuario. Por ejemplo, johnstiles@example.com.

Cuando utilices un SharePoint grupo para filtrar los resultados de la búsqueda, calcula el ID del grupo de la siguiente manera:

Para grupos locales

  1. Obtenga el nombre del sitio. Por ejemplo, https://host.onmicrosoft.com/sites/siteName.

  2. Tome el hash SHA256 del nombre del sitio. Por ejemplo, 430a6b90503eef95c89295c8999c7981.

  3. Cree el ID del grupo concatenando el hash SHA256 con una barra vertical (|) y el nombre del grupo. Por ejemplo, si el nombre del grupo es "localGroupName«, el ID del grupo sería:

    "430a6b90503eef95c89295c8999c7981 | localGroupName"

    nota

    Incluye un espacio antes y después de la barra vertical. La barra vertical se utiliza para identificarse localGroupName con su hash SHA256.

Envía el ID de grupo Amazon Kendra como _group_id atributo cuando llames a la API de consulta. Por ejemplo, el AWS CLI comando tiene este aspecto:

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

Para grupos de AD

  1. Usa el ID de grupo de AD para configurar el filtrado de los resultados de búsqueda.

Envía el ID de grupo Amazon Kendra como _group_id atributo cuando llames a la API de consultas. Por ejemplo, el AWS CLI comando tiene este aspecto:

aws kendra query \ --index-id index ID --query-text "query text" --attribute-filter '{ "EqualsTo":{ "Key": "_group_id", "Value": {"StringValue": "AD group"} }}'

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para orígenes de datos de Microsoft SQL Server.

Cuando utiliza una fuente de datos de Microsoft SQL Server, Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Un origen de datos de la base de datos de Microsoft SQL Server tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para orígenes de datos de Microsoft Teams

Amazon Kendra recupera la información de usuario de Microsoft Teams cuando indexa los documentos. La información del usuario se toma de la instancia de Microsoft Teams subyacente.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para orígenes de datos de Microsoft Yammer

Amazon Kendra recupera la información del usuario de Microsoft Yammer cuando indexa los documentos. La información de usuario y grupo se toma de la instancia subyacente de Microsoft Yammer.

Los ID de usuario de Microsoft Yammer se asignan de la siguiente manera:

  • _email_id— El ID de correo electrónico de Microsoft asignado al _user_id campo.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de MySQL

Cuando utiliza una fuente de datos MySQL, Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Un origen de datos de la base de datos de MySQL tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Oracle Database

Cuando utiliza una fuente de datos de Oracle Database, Amazon Kendra obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Un origen de datos de la base de datos de Oracle Database tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de PostgreSQL

Cuando utiliza una fuente de datos de PostgreSQL Amazon Kendra , obtiene información de usuarios y grupos de una columna de la tabla de fuentes. Esta columna se especifica en la consola o se utiliza el TemplateConfigurationobjeto como parte de la CreateDataSourceAPI.

Un origen de datos de la base de datos de PostgreSQL tiene las siguientes limitaciones:

  • Solo puede especificar una lista de permisos para un origen de datos de la base de datos. No puede especificar una lista de denegaciones.

  • Solo puede especificar grupos. No puede especificar usuarios individuales para la lista de permisos.

  • La columna de la base de datos debe ser una cadena que contenga una lista de grupos delimitada por punto y coma.

Filtrado por contexto de usuario para los orígenes de datos de Quip

Cuando utiliza una fuente de datos de Quip, Amazon Kendra obtiene la información de usuario de la instancia de Quip.

Los ID de usuario de Quip se asignan de la siguiente manera:

  • _user_id: los ID de usuario existen en Quip en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Quip.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Salesforce

Un origen de datos de Salesforce devuelve información de usuarios y grupos a partir de las entidades de la lista de control de acceso (ACL) de Salesforce. Puede aplicar el filtrado por contexto de usuario a los objetos estándar o las fuentes de chat de Salesforce. El filtrado por contexto de usuario no está disponible para los artículos de conocimiento de Salesforce.

Si asigna cualquier campo de Salesforce a los campos de título y cuerpo del documento de Amazon Kendra, Amazon Kendra utilizará los datos de los campos de título y cuerpo del documento en las respuestas de búsqueda.

En el caso de los objetos estándar, los _user_id y _group_ids se utilizan de la siguiente manera:

  • _user_id: el nombre de usuario del usuario de Salesforce.

  • _group_ids

    • Nombre de Profile de Salesforce

    • Nombre de Group de Salesforce

    • Nombre de UserRole de Salesforce

    • Nombre de PermissionSet de Salesforce

Para las fuentes de chat, los _user_id y _group_ids se utilizan de la siguiente manera:

  • _user_id: el nombre de usuario del usuario de Salesforce. Solo está disponible si el elemento está publicado en la fuente del usuario.

  • _group_ids: los ID de grupo se utilizan de la siguiente manera. Solo está disponible si el elemento de la fuente se publica en un grupo de colaboración o chat.

    • El nombre del grupo de colaboración o chat.

    • Si el grupo es público, PUBLIC:ALL.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de ServiceNow

El filtrado del contexto de usuario solo ServiceNow se admite en la TemplateConfiguration API y ServiceNow en la versión 2.0 de Connector. ServiceNowConfigurationLa API y ServiceNow Connector v1.0 no admiten el filtrado del contexto de los usuarios.

Cuando usa una fuente de ServiceNow datos, Amazon Kendra obtiene la información de usuario y grupo de la ServiceNow instancia.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids—Los ID de grupo existen ServiceNow en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los roles de sys_ids in. ServiceNow

  • _user_id—Los ID de usuario existen en los archivos ServiceNow en los que hay permisos de acceso establecidos. Se mapean a partir de los correos electrónicos de los usuarios como identificadores. ServiceNow

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Slack

Cuando utilizas una fuente de datos de Slack, Amazon Kendra obtiene la información del usuario de la instancia de Slack.

Los ID de usuario de Slack se asignan de la siguiente manera:

  • _user_id: los ID de usuario existen en Slack en los mensajes y canales en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Slack.

Puede añadir hasta 200 entradas en el campo AccessControlList.

Filtrado por contexto de usuario para los orígenes de datos de Zendesk

Cuando se utiliza una fuente de datos de Zendesk, Amazon Kendra obtiene la información del usuario y del grupo de la instancia de Zendesk.

Los ID de grupo y usuario se asignan de la siguiente manera:

  • _group_ids: los ID de grupo existen en los tickets y artículos de Zendesk en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de los grupos en Zendesk.

  • _user_id: los ID de grupo existen en los tickets y artículos de Zendesk en los que hay permisos de acceso establecidos. Se asignan a partir de los correos electrónicos de los usuarios como los ID en Zendesk.

Puede añadir hasta 200 entradas en el campo AccessControlList.