Filtrar por contexto de usuario
nota
La compatibilidad de características varía según el tipo de índice y la API de búsqueda que se use. Para comprobar si esta característica es compatible con el tipo de índice y la API de búsqueda que usa, consulte Tipos de índices.
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 documentos.
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 en 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 los orígenes 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 añade documentos directamente a un índice, especifique la ACL en el objeto Principal como parte del objeto de documento en la API BatchPutDocument.
Si utiliza un índice Enterprise o Developer Edition de Amazon Kendra, puede utilizar la API CreateAccessControlConfiguration para volver a configurar el control de acceso en el 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 su configuración de control de acceso a determinados documentos, debe llamar a la API BatchPutDocument con el AccessControlConfigurationId incluido en el objeto Documento. Si utiliza un bucket de S3 como origen de datos, actualice el .metadata.json con el AccessControlConfigurationId y sincronice el origen de datos. Actualmente, Amazon Kendra solo admite la configuración de control de acceso para los orígenes de datos de S3 y los documentos indexados mediante la API BatchPutDocument.
Filtrado por token de usuario
importante
Los índices GenAI Enterprise Edition de Amazon Kendra no son compatibles con el control de acceso de usuarios basado en tokens.
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 objeto UserContext y pasarlo a la API de consulta.
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 API PutPrincipalMapping, puede asignar los 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 en su origen de identidad de IAM Identity Center mediante el objeto UserGroupResolutionConfiguration.
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 los orígenes de datos en el objeto UserContext y pasarlo a la API de consulta. 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 orígenes de datos mediante la API PutPrincipalMapping. También puede obtener los niveles de acceso de los grupos y usuarios en su origen de identidad de IAM Identity Center mediante el objeto UserGroupResolutionConfiguration.
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, UserContext={'Token': 'string', 'UserId': 'string', 'Groups': [ 'string', ], 'DataSourceGroups': [ { 'GroupId': 'string', 'DataSourceId': 'string' }, ] },)
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 de grupo en el objeto AttributeFilter y pasarlo a la API de consulta.
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.
Temas
Filtrado por contexto de usuario para los documentos añadidos directamente a un índice
Al añadir documentos directamente a un índice mediante la API BatchPutDocument, Amazon Kendra obtiene información de los usuarios y grupos del campo AccessControlList 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
ALLOWoDENY. -
El tipo de entidad. Puede decir
USERoGROUP. -
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
Cuando añade una pregunta frecuente a un índice, Amazon Kendra obtiene información del usuario y el grupo del objeto o campo AccessControlList 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
ALLOWoDENY. -
El tipo de entidad. Puede decir
USERoGROUP. -
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 los usuarios y grupos desde los conectores de orígenes 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.
importante
Los índices GenAI Enterprise Edition de Amazon Kendra solo son compatibles con los conectores de orígenes de datos de Amazon Kendra v2.0.
Temas
Filtrado por contexto de usuario para los orígenes de datos de Adobe Experience Manager
Filtrado por contexto de usuario para los orígenes de datos de Alfresco
Filtrado por contexto de usuario para los orígenes de datos de Aurora (MySQL)
Filtrado por contexto de usuario para los orígenes de datos de Aurora (PostgreSQL)
Filtrado por contexto de usuario para los orígenes de datos de Amazon FSx
Filtrado por contexto de usuario para los orígenes de datos de bases de datos
Filtrado por contexto de usuario para orígenes de datos de Amazon RDS (Microsoft SQL Server).
Filtrado por contexto de usuario para los orígenes de datos de Amazon RDS (MySQL)
Filtrado por contexto de usuario para los orígenes de datos Amazon RDS (Oracle)
Filtrado por contexto de usuario para los orígenes de datos de Amazon RDS (PostgreSQL)
Filtrado por contexto de usuario para los orígenes de datos de Amazon S3
Filtrado por contexto de usuario para los orígenes de datos de Box
Filtrado por contexto de usuario para los orígenes de datos de Confluence
Filtrado por contexto de usuario para los orígenes de datos de Dropbox
Filtrado por contexto de usuario para los orígenes de datos de Drupal
Filtrado por contexto de usuario para los orígenes de datos de GitHub
Filtrado por contexto de usuario para los orígenes de datos de Gmail
Filtrado por contexto de usuario para los orígenes de datos de Google Drive
Filtrado por contexto de usuario para los orígenes de datos de IBM DB2
Filtrado por contexto de usuario para los orígenes de datos de Jira
Filtrado por contexto de usuario para orígenes de datos de Microsoft Exchange
Filtrado por contexto de usuario para orígenes de datos de Microsoft OneDrive
Filtrado por contexto de usuario para orígenes de datos de Microsoft OneDrive v2.0
Filtrado por contexto de usuario para orígenes de datos de Microsoft SharePoint
Filtrado por contexto de usuario para orígenes de datos de Microsoft SQL Server.
Filtrado por contexto de usuario para orígenes de datos de Microsoft Teams
Filtrado por contexto de usuario para orígenes de datos de Microsoft Yammer
Filtrado por contexto de usuario para los orígenes de datos de MySQL
Filtrado por contexto de usuario para los orígenes de datos de Oracle Database
Filtrado por contexto de usuario para los orígenes de datos de PostgreSQL
Filtrado por contexto de usuario para los orígenes de datos de Quip
Filtrado por contexto de usuario para los orígenes de datos de Salesforce
Filtrado por contexto de usuario para los orígenes de datos de ServiceNow
Filtrado por contexto de usuario para los orígenes de datos de Slack
Filtrado por contexto de usuario para los orígenes de datos de Zendesk
Filtrado por contexto de usuario para los orígenes de datos de Adobe Experience Manager
Cuando utiliza un origen de datos de Adobe Experience Manager, Amazon Kendra obtiene la información del usuario y del 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 un origen de datos de Alfresco, Amazon Kendra obtiene la información del usuario y el 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 por contexto de usuario para los orígenes de datos de Aurora (MySQL)
Cuando utiliza un origen de datos de Aurora (MySQL), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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 un origen de datos de Aurora (PostgreSQL), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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 por contexto de usuario para los orígenes de datos de Amazon FSx
Cuando utiliza un origen de datos de Amazon FSx, Amazon Kendra obtiene la información del usuario y el grupo del servicio de directorio de la instancia de Amazon FSx.
Los ID de grupo y usuario de Amazon FSx se asignan 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 grupo del sistema en el servicio de directorio de Amazon FSx. -
_user_id: los ID de usuario existen en Amazon FSx en los archivos 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 un origen de datos de bases de datos, como Amazon Aurora PostgreSQL, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en el objeto AclConfiguration como parte del objeto DatabaseConfiguration de la API CreateDataSource.
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 un origen de datos de Amazon RDS (Microsoft SQL Server), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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 por contexto de usuario para los orígenes de datos de Amazon RDS (MySQL)
Cuando utiliza un origen de datos de Amazon RDS (MySQL), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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 por contexto de usuario para los orígenes de datos Amazon RDS (Oracle)
Cuando utiliza un origen de datos de Amazon RDS (Oracle), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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 un origen de datos de Amazon RDS (PostgreSQL), Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
Un origen de datos de la base de datos de 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
Puede añadir un filtrado por contexto de usuario a un documento de un origen de datos de Amazon S3 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
ALLOWoDENY. -
El tipo de entidad. Puede decir
USERoGROUP. -
El nombre de la entidad.
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 un origen de datos de Box, Amazon Kendra obtiene la información del usuario y el grupo 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 utiliza un origen de datos de Confluence, Amazon Kendra obtiene la información del usuario y el grupo 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
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_ides el nombre de usuario. El nombre de usuario siempre está en minúscula. -
Nube:
_user_ides el ID de cuenta del usuario.
Para el conector de Confluence v2.0
-
Servidor:
_user_ides el nombre de usuario. El nombre de usuario siempre está en minúscula. -
Nube:
_user_ides 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 utiliza un origen de datos de Dropbox, Amazon Kendra obtiene la información del usuario y el 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 utiliza un origen de datos de Drupal, Amazon Kendra obtiene la información del usuario y el 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 por contexto de usuario para los orígenes de datos de GitHub
Cuando utiliza un origen de datos de GitHub, Amazon Kendra obtiene la información del usuario de la instancia de GitHub.
Los ID de usuario de GitHub se asignan de la siguiente manera:
-
_user_id: los ID de usuario existen en GitHub 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 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 utiliza un origen 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 un origen de datos de IBM DB2, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
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 utiliza un origen de datos de Jira, Amazon Kendra obtiene la información del usuario y el grupo 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 un origen de datos de Microsoft Exchange, Amazon Kendra obtiene la información de usuario de la instancia de Microsoft Exchange.
Los ID de usuario de Microsoft Yammer 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 los usuarios como los ID en Microsoft Exchange.
Puede añadir hasta 200 entradas en el campo AccessControlList.
Filtrado por contexto de usuario para orígenes de datos de Microsoft OneDrive
Amazon Kendra recupera la información de usuario y grupo de Microsoft OneDrive cuando indexa los documentos en el sitio. La información de usuario y grupo se toma del sitio subyacente de Microsoft SharePoint que aloja OneDrive.
Cuando use un usuario o un grupo de OneDrive para filtrar por resultados de búsqueda, calcule el ID de la siguiente manera:
-
Obtenga el nombre del sitio. Por ejemplo: .,
https://host.onmicrosoft.com/sites/siteName. -
Tome el hash MD5 del nombre del sitio. Por ejemplo,
430a6b90503eef95c89295c8999c7981. -
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 de grupo sería:
"430a6b90503eef95c89295c8999c7981 | localGroupName"nota
Incluya un espacio antes y después de la barra vertical. La barra vertical se utiliza para identificar
localGroupNamecon 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íe el ID de usuario o grupo a Amazon Kendra como el atributo _user_id o _group_id cuando llame a la API de consulta. Por ejemplo, el comando AWS CLI que usa un grupo para filtrar los resultados de búsqueda tiene el siguiente aspecto:
aws kendra query \ --index-idindex 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 por contexto de usuario para orígenes de datos de Microsoft OneDrive v2.0
Un origen de datos de Microsoft OneDrive v2.0 devuelve información de secciones y páginas de las entidades de la lista de control de acceso (ACL) de OneDrive. Amazon Kendra usa el dominio de inquilino de OneDrive para conectarse a la instancia de OneDrive y puede filtrar resultados de búsqueda según el acceso del grupo o los usuarios a secciones y nombres de 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 de correo electrónico de usuario de Microsoft OneDrive se asigna al campo_user_id. -
_group_id: su correo electrónico de grupo de Microsoft OneDrive se asigna al campo_group_id.
Puede añadir hasta 200 entradas en el campo AccessControlList.
Filtrado por contexto de usuario para orígenes de datos de Microsoft SharePoint
Amazon Kendra recupera la información de usuario y grupo 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 los grupos, proporcione información del usuario y el grupo cuando llame a la API Query.
Para filtrar mediante un nombre de usuario, utilice la dirección de correo electrónico del usuario. Por ejemplo, johnstiles@example.com.
Cuando utilice un grupo de SharePoint para filtrar resultados de búsqueda, calcule el ID de grupo de la siguiente manera:
Para grupos locales
-
Obtenga el nombre del sitio. Por ejemplo: .,
https://host.onmicrosoft.com/sites/siteName. -
Tome el hash SHA256 del nombre del sitio. Por ejemplo,
430a6b90503eef95c89295c8999c7981. -
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 de grupo sería:
"430a6b90503eef95c89295c8999c7981 | localGroupName"nota
Incluya un espacio antes y después de la barra vertical. La barra vertical se utiliza para identificar
localGroupNamecon su hash SHA256.
Envíe el ID de grupo a Amazon Kendra como el atributo _group_id cuando llame a la API de consulta. Por ejemplo, el comando de la AWS CLI tiene este aspecto:
aws kendra query \ --index-idindex ID--query-text "query text" --attribute-filter '{ "EqualsTo":{ "Key": "_group_id", "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"} }}'
Para grupos de AD
-
Utilice el ID de grupo de AD para configurar el filtrado de los resultados de búsqueda.
Envíe el ID de grupo a Amazon Kendra como el atributo _group_id cuando llame a la API de consulta. Por ejemplo, el comando de la AWS CLI tiene este aspecto:
aws kendra query \ --index-idindex 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 un origen de datos de Microsoft SQL Server, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
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 de 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 de usuario de Microsoft Yammer cuando indexa los documentos. La información de usuario y grupo se toma de la instancia de Microsoft Yammer subyacente.
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 campo_user_id.
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 un origen de datos de MySQL, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
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 un origen de datos de Oracle Database, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
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 un origen de datos de PostgreSQL, Amazon Kendra obtiene información de los usuarios y los grupos de una columna de la tabla de origen. Debe especificar esta columna en la consola o utilizar el objeto TemplateConfiguration como parte de la API CreateDataSource.
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 un origen de datos de Quip, Amazon Kendra obtiene la información del 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 algún campo de Salesforce a los campos del título y cuerpo del documento de Amazon Kendra, Amazon Kendra utilizará datos de los campos del título y el 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
Profilede Salesforce -
Nombre de
Groupde Salesforce -
Nombre de
UserRolede Salesforce -
Nombre de
PermissionSetde 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 por contexto de usuario para ServiceNow solo es compatible con la API TemplateConfiguration y ServiceNow Connector v2.0. La API ServiceNowConfiguration y ServiceNow Connector v1.0 no admiten el filtrado por contexto de usuario.
Cuando utiliza un origen de datos de ServiceNow, Amazon Kendra obtiene la información del usuario y el grupo de la instancia de ServiceNow.
Los ID de grupo y usuario se asignan de la siguiente manera:
-
_group_ids: los ID de grupo existen en ServiceNow en los archivos en los que hay permisos de acceso establecidos. Se asignan a partir de los nombres de rol desys_idsen ServiceNow. -
_user_id: los ID de usuario existen en ServiceNow 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 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 utiliza un origen 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 utiliza un origen de datos de Zendesk, Amazon Kendra obtiene la información del usuario y el 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.