Filtrage en fonction du contexte utilisateur - Amazon Kendra
Filtrage par jeton utilisateurFiltrage par nom d'utilisateur et par groupeFiltrage par attribut utilisateurFiltrage du contexte utilisateur pour les documents ajoutés directement à un indexFiltrage du contexte utilisateur pour les questions fréquemment poséesFiltrage du contexte utilisateur pour les sources de données

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Filtrage en fonction du contexte utilisateur

Vous pouvez filtrer les résultats de recherche d'un utilisateur en fonction de l'accès de celui-ci ou de son groupe aux documents. Vous pouvez utiliser un jeton utilisateur, un ID utilisateur ou un attribut utilisateur pour filtrer les documents. Amazon Kendra peut également associer les utilisateurs à leurs groupes. Vous pouvez choisir de l'utiliser AWS IAM Identity Center comme magasin/source d'identité.

Le filtrage du contexte utilisateur est une sorte de recherche personnalisée qui a l'avantage de contrôler l'accès aux documents. Par exemple, les équipes qui recherchent des informations sur le portail de l'entreprise ne doivent pas toutes accéder aux documents top secrets de l'entreprise, et ces documents ne sont pas pertinents pour tous les utilisateurs. Seuls des utilisateurs ou des groupes d'équipes spécifiques ayant accès à des documents top secrets devraient voir ces documents dans leurs résultats de recherche.

Lorsqu'un document est indexé dans Amazon Kendra, une liste de contrôle d'accès (ACL) correspondante est ingérée pour la plupart des documents. L'ACL indique les noms d'utilisateur et de groupe auxquels l'accès au document est autorisé ou refusé. Les documents sans ACL sont des documents publics.

Amazon Kendra peut extraire les informations d'utilisateur ou de groupe associées à chaque document pour la plupart des sources de données. Par exemple, un document dans Quip peut inclure une liste « partagée » de certains utilisateurs autorisés à accéder au document. Si vous utilisez un compartiment S3 comme source de données, vous fournissez un fichier JSON pour votre ACL et vous incluez le chemin S3 vers ce fichier dans le cadre de la configuration de la source de données. Si vous ajoutez des documents directement à un index, vous spécifiez l'ACL dans l'objet Principal en tant que partie intégrante de l'objet document dans l'BatchPutDocumentAPI.

Vous pouvez utiliser l'CreateAccessControlConfigurationAPI pour reconfigurer le contrôle d'accès au niveau des documents existant sans devoir indexer à nouveau tous vos documents. Par exemple, votre index contient des documents d'entreprise top secrets auxquels seuls certains employés ou utilisateurs peuvent accéder. L'un de ces utilisateurs quitte l'entreprise ou rejoint une équipe qui devrait être empêchée d'accéder à des documents top secrets. L'utilisateur a toujours accès aux documents top secrets car il y avait accès lors de l'indexation précédente de vos documents. Vous pouvez créer une configuration de contrôle d'accès spécifique pour l'utilisateur en lui refusant l'accès. Vous pouvez ultérieurement mettre à jour la configuration du contrôle d'accès pour autoriser l'accès au cas où l'utilisateur reviendrait dans l'entreprise et rejoindrait l'équipe « top-secrète ». Vous pouvez reconfigurer le contrôle d'accès à vos documents en fonction de l'évolution des circonstances.

Pour appliquer votre configuration de contrôle d'accès à certains documents, vous appelez l'BatchPutDocumentAPI avec l'objet AccessControlConfigurationId inclus dans le document. Si vous utilisez un compartiment S3 comme source de données, vous le mettez à jour .metadata.json avec la source de données AccessControlConfigurationId et vous le synchronisez. Amazon Kendra ne prend actuellement en charge que la configuration du contrôle d'accès pour les sources de données S3 et les documents indexés à l'aide de l'BatchPutDocumentAPI.

Filtrage par jeton utilisateur

Lorsque vous interrogez un index, vous pouvez utiliser un jeton utilisateur pour filtrer les résultats de recherche en fonction de l'accès de l'utilisateur ou de son groupe aux documents. Lorsque vous émettez une requête, Amazon Kendra extrayez et validez le jeton, extrayez et vérifiez les informations relatives à l'utilisateur et au groupe, puis exécutez la requête. Tous les documents auxquels l'utilisateur a accès, y compris les documents publics, sont renvoyés. Pour plus d'informations, consultez la section Contrôle d'accès utilisateur basé sur des jetons.

Vous fournissez le jeton utilisateur dans l'UserContextobjet et vous le transmettez à l'API Query.

Ce qui suit montre comment inclure un jeton utilisateur. 

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

Vous pouvez associer des utilisateurs à des groupes. Lorsque vous utilisez le filtrage contextuel utilisateur, il n'est pas nécessaire d'inclure tous les groupes auxquels appartient un utilisateur lorsque vous émettez la requête. Avec l'PutPrincipalMappingAPI, vous pouvez associer les utilisateurs à leurs groupes. Si vous ne souhaitez pas utiliser l'PutPrincipalMappingAPI, vous devez fournir le nom d'utilisateur et tous les groupes auxquels il appartient lorsque vous émettez une requête. Vous pouvez également récupérer les niveaux d'accès des groupes et des utilisateurs dans votre source d'identité IAM Identity Center à l'aide de l'UserGroupResolutionConfigurationobjet.

Filtrage par nom d'utilisateur et par groupe

Lorsque vous interrogez un index, vous pouvez utiliser l'ID utilisateur et le groupe pour filtrer les résultats de recherche en fonction de l'accès de l'utilisateur ou de son groupe aux documents. Lorsque vous émettez une requête, Amazon Kendra vérifie les informations relatives à l'utilisateur et au groupe et exécute la requête. Tous les documents relatifs à la requête auxquels l'utilisateur a accès, y compris les documents publics, sont renvoyés.

Vous pouvez également filtrer les résultats de recherche en fonction des sources de données auxquelles les utilisateurs et les groupes ont accès. La spécification d'une source de données est utile si un groupe est lié à plusieurs sources de données, mais que vous souhaitez uniquement que le groupe accède aux documents d'une certaine source de données. Par exemple, les groupes « Recherche », « Ingénierie » et « Ventes et marketing » sont tous liés aux documents de l'entreprise stockés dans les sources de données Confluence et Salesforce. Toutefois, l'équipe « Ventes et marketing » n'a besoin d'accéder qu'aux documents relatifs aux clients stockés dans Salesforce. Ainsi, lorsque les utilisateurs des ventes et du marketing recherchent des documents relatifs aux clients, ils peuvent voir les documents de Salesforce dans leurs résultats. Les utilisateurs qui ne travaillent pas dans le domaine des ventes et du marketing ne voient pas les documents Salesforce dans leurs résultats de recherche.

Vous fournissez les informations relatives aux utilisateurs, aux groupes et aux sources de données dans l'UserContextobjet et vous les transmettez à l'API Query. L'ID utilisateur et la liste des groupes et des sources de données doivent correspondre au nom que vous spécifiez dans l'objet Principal pour identifier l'utilisateur, les groupes et les sources de données. Avec Principal cet objet, vous pouvez ajouter un utilisateur, un groupe ou une source de données à une liste d'autorisation ou de refus d'accès à un document.

Vous devez fournir l'un des éléments suivants :

  • Informations sur les utilisateurs et les groupes, et informations (facultatives) sur les sources de données.

  • Uniquement les informations utilisateur si vous mappez vos utilisateurs à des groupes et à des sources de données à l'aide de l'PutPrincipalMappingAPI. Vous pouvez également récupérer les niveaux d'accès des groupes et des utilisateurs dans votre source d'identité IAM Identity Center à l'aide de l'UserGroupResolutionConfigurationobjet.

Si ces informations ne sont pas incluses dans la requête, Amazon Kendra renvoie tous les documents. Si vous fournissez ces informations, seuls les documents dont les noms d'utilisateur, les groupes et les sources de données correspondent sont renvoyés.

Ce qui suit montre comment inclure l'ID utilisateur, les groupes et les sources de données.

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

Filtrage par attribut utilisateur

Lorsque vous interrogez un index, vous pouvez utiliser des attributs intégrés _user_id et filtrer _group_id les résultats de recherche en fonction de l'accès de l'utilisateur et de son groupe aux documents. Vous pouvez configurer jusqu'à 100 identifiants de groupe. Lorsque vous émettez une requête, Amazon Kendra vérifie les informations relatives à l'utilisateur et au groupe et exécute la requête. Tous les documents relatifs à la requête auxquels l'utilisateur a accès, y compris les documents publics, sont renvoyés.

Vous fournissez les attributs d'utilisateur et de groupe dans l'AttributeFilterobjet et vous les transmettez à l'API Query.

L'exemple suivant montre une demande qui filtre la réponse à la requête en fonction de l'ID utilisateur et des groupes « HR » et « IT » auxquels appartient l'utilisateur. La requête renverra tout document dont l'utilisateur ou les groupes « RH » ou « IT » figurent dans la liste des documents autorisés. Si l'utilisateur ou l'un des groupes figure dans la liste de refus d'un document, le document n'est pas renvoyé.

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

Vous pouvez également spécifier à quelle source de données un groupe peut accéder dans l'Principalobjet.

Note

Le filtrage du contexte utilisateur n'est pas un contrôle d'authentification ou d'autorisation pour votre contenu. Il n'authentifie pas l'utilisateur et les groupes envoyés à l'QueryAPI. Il appartient à votre application de s'assurer que les informations relatives aux utilisateurs et aux groupes envoyées à Query l'API sont authentifiées et autorisées.

Il existe une implémentation du filtrage du contexte utilisateur pour chaque source de données. La section suivante décrit chaque implémentation.

Filtrage du contexte utilisateur pour les documents ajoutés directement à un index

Lorsque vous ajoutez des documents directement à un index à l'aide de l'BatchPutDocumentAPI, les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites du AccessControlList champ du document. Vous fournissez une liste de contrôle d'accès (ACL) pour vos documents et l'ACL est ingérée avec vos documents.

Vous spécifiez l'ACL dans l'objet Principal dans le cadre de l'objet Document de l'BatchPutDocumentAPI. Vous fournissez les informations suivantes :

  • L'accès que l'utilisateur ou le groupe doit avoir. Tu peux dire ALLOW ouDENY.

  • Type d'entité. Tu peux dire USER ouGROUP.

  • Nom de l'utilisateur ou du groupe.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les questions fréquemment posées

Lorsque vous ajoutez une FAQ à un index, vous obtenez des informations sur Amazon Kendra les utilisateurs et les groupes à partir de l'AccessControlListobjet/champ du fichier JSON de la FAQ. Vous pouvez également utiliser un fichier CSV de FAQ avec des champs ou des attributs personnalisés pour le contrôle d'accès.

Vous fournissez les informations suivantes :

  • L'accès que l'utilisateur ou le groupe doit avoir. Tu peux dire ALLOW ouDENY.

  • Type d'entité. Tu peux dire USER ouGROUP.

  • Nom de l'utilisateur ou du groupe.

Pour plus d'informations, consultez les fichiers de FAQ.

Filtrage du contexte utilisateur pour les sources de données

Amazon Kendra analyse également les informations des listes de contrôle d'accès (ACL) des utilisateurs et des groupes à partir des connecteurs de source de données pris en charge. Cela est utile pour le filtrage du contexte utilisateur, où les résultats de recherche sont filtrés en fonction de l'accès de l'utilisateur ou de son groupe aux documents.

Rubriques

Filtrage du contexte utilisateur pour les sources de données Adobe Experience Manager

Lorsque vous utilisez une source de données Adobe Experience Manager, vous obtenez les Amazon Kendra informations relatives aux utilisateurs et aux groupes à partir de l'instance d'Adobe Experience Manager.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans le contenu d'Adobe Experience Manager où des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Adobe Experience Manager.

  • _user_id—Les identifiants utilisateur existent dans le contenu d'Adobe Experience Manager où des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs sous forme d'identifiants dans Adobe Experience Manager.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Alfresco

Lorsque vous utilisez une source de données Alfresco, les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites de l'instance Alfresco.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans Alfresco pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms système des groupes (et non des noms d'affichage) dans Alfresco.

  • _user_id—Des identifiants utilisateur existent dans Alfresco pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants dans Alfresco.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Aurora (MySQL)

Lorsque vous utilisez une source de données Aurora (MySQL), les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Aurora (MySQL) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les Aurora sources de données (PostgreSQL)

Lorsque vous utilisez une source de données Aurora (PostgreSQL) Amazon Kendra , les informations relatives aux utilisateurs et aux groupes sont extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Aurora (PostgreSQL) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources Amazon FSx de données

Lorsque vous utilisez une source de Amazon FSx données, Amazon Kendra elle obtient des informations sur les utilisateurs et les groupes à partir du service d'annuaire de l' Amazon FSx instance.

Les identifiants de Amazon FSx groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans Amazon FSx les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms de groupes de systèmes dans le service d'annuaire de Amazon FSx.

  • _user_id—Les identifiants utilisateur existent dans Amazon FSx les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms d'utilisateur du système dans le service d'annuaire de Amazon FSx.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données de base de données

Lorsque vous utilisez une source de données de base de données, telle que Amazon Aurora PostgreSQL, Amazon Kendra obtient des informations sur les utilisateurs et les groupes à partir d'une colonne de la table source. Vous spécifiez cette colonne dans l'AclConfigurationobjet en tant que partie intégrante de l'DatabaseConfigurationobjet dans l'CreateDataSourceAPI.

Une source de données de base de données présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Amazon RDS (Microsoft SQL Server)

Lorsque vous utilisez une source de données Amazon RDS (Microsoft SQL Server), les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Amazon RDS (Microsoft SQL Server) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Amazon RDS (MySQL)

Lorsque vous utilisez une source de données Amazon RDS (MySQL), les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Amazon RDS (MySQL) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Amazon RDS (Oracle)

Lorsque vous utilisez une source de données Amazon RDS (Oracle), les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Amazon RDS (Oracle) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les Amazon RDS sources de données (PostgreSQL)

Lorsque vous utilisez une source de données Amazon RDS (PostgreSQL) Amazon Kendra , les informations relatives aux utilisateurs et aux groupes sont extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Amazon RDS (PostgreSQL) présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources Amazon S3 de données

Vous ajoutez un filtrage contextuel utilisateur à un document dans une source de Amazon S3 données à l'aide d'un fichier de métadonnées associé au document. Vous ajoutez les informations dans le AccessControlList champ du document JSON. Pour plus d'informations sur l'ajout de métadonnées aux documents indexés à partir d'une source de Amazon S3 données, consultez la section Métadonnées des documents S3.

Vous fournissez trois informations :

  • L'accès que l'entité doit avoir. Tu peux dire ALLOW ouDENY.

  • Type d'entité. Tu peux dire USER ouGROUP.

  • Le nom de l'entité.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources Amazon WorkDocs de données

Lorsque vous utilisez une source de Amazon WorkDocs données, Amazon Kendra elle obtient des informations sur les utilisateurs et les groupes à partir de l' Amazon WorkDocs instance.

Les identifiants de Amazon WorkDocs groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans Amazon WorkDocs les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Amazon WorkDocs.

  • _user_id—Les identifiants utilisateur existent dans Amazon WorkDocs les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms d'utilisateur contenus dans Amazon WorkDocs.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Box

Lorsque vous utilisez une source de données Box, Amazon Kendra vous obtenez des informations sur les utilisateurs et les groupes à partir de l'instance Box.

Le groupe Box et les identifiants utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans Box pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Box.

  • _user_id—Les identifiants utilisateur existent dans Box pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs sous forme d'identifiants utilisateur dans Box.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Confluence

Lorsque vous utilisez une source de données Confluence, Amazon Kendra elle obtient des informations sur les utilisateurs et les groupes à partir de l'instance Confluence.

Vous configurez l'accès des utilisateurs et des groupes aux espaces à l'aide de la page des autorisations d'espace. Pour les pages et les blogs, vous utilisez la page des restrictions. Pour plus d'informations sur les autorisations d'espace, consultez la section Vue d'ensemble des autorisations d'espace sur le site Web d'assistance de Confluence. Pour plus d'informations sur les restrictions relatives aux pages et aux blogs, consultez la section Restrictions relatives aux pages sur le site Web d'assistance de Confluence.

Le groupe Confluence et les noms d'utilisateur sont mappés comme suit :

  • _group_ids—Les noms de groupes sont présents sur les espaces, les pages et les blogs soumis à des restrictions. Ils sont mappés à partir du nom du groupe dans Confluence. Les noms de groupes sont toujours en minuscules.

  • _user_id—Les noms d'utilisateur sont présents sur l'espace, la page ou le blog soumis à des restrictions. Ils sont mappés en fonction du type d'instance Confluence que vous utilisez.

    Pour connecteur Confluence v1.0

    • Serveur : il _user_id s'agit du nom d'utilisateur. Le nom d'utilisateur est toujours en minuscules.

    • Cloud : il _user_id s'agit de l'ID de compte de l'utilisateur.

    Pour connecteur Confluence v2.0

    • Serveur : il _user_id s'agit du nom d'utilisateur. Le nom d'utilisateur est toujours en minuscules.

    • Cloud : il _user_id s'agit de l'identifiant e-mail de l'utilisateur.

    Important

    Pour que le filtrage du contexte utilisateur fonctionne correctement pour votre connecteur Confluence, vous devez vous assurer que la visibilité d'un utilisateur autorisé à accéder à une page Confluence est définie sur Tout le monde. Pour plus d'informations, consultez la section Configurer la visibilité de vos e-mails dans la documentation Atlassian destinée aux développeurs.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Dropbox

Lorsque vous utilisez une source de données Dropbox, les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites de l'instance Dropbox.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Des identifiants de groupe existent dans Dropbox pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Dropbox.

  • _user_id—Des identifiants utilisateur existent dans Dropbox pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs sous forme d'identifiants dans Dropbox.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Drupal

Lorsque vous utilisez une source de données Drupal, vous obtenez les informations de l' Amazon Kendra utilisateur et du groupe à partir de l'instance Drupal.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids— Les identifiants de groupe existent dans Drupal sur les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Drupal.

  • _user_id— Les identifiants utilisateur existent dans Drupal sur les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants dans Drupal.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources GitHub de données

Lorsque vous utilisez une source de GitHub données, Amazon Kendra obtient les informations utilisateur de l' GitHub instance.

Les identifiants GitHub utilisateur sont mappés comme suit :

  • _user_id—Les identifiants utilisateur existent dans GitHub les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs au fur et à mesure que les identifiants entrent. GitHub

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Gmail

Lorsque vous utilisez une source de données Gmail, Amazon Kendra obtient les informations utilisateur de l'instance Gmail.

Les identifiants utilisateur sont mappés comme suit :

  • _user_id— Les identifiants utilisateur existent dans Gmail pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants dans Gmail.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Google Drive

Une source de données Google Workspace Drive renvoie des informations sur les utilisateurs et les groupes relatifs aux utilisateurs et aux groupes de Google Drive. L'appartenance au groupe et au domaine est mappée au champ d'_group_idsindex. Le nom d'utilisateur Google Drive est associé au _user_id champ.

Lorsque vous fournissez une ou plusieurs adresses e-mail utilisateur dans l'QueryAPI, seuls les documents partagés avec ces adresses e-mail sont renvoyés. Le AttributeFilter paramètre suivant renvoie uniquement les documents partagés avec "martha@example.com ».

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

Si vous fournissez une ou plusieurs adresses e-mail de groupe dans la requête, seuls les documents partagés avec les groupes sont renvoyés. Le AttributeFilter paramètre suivant renvoie uniquement les documents partagés avec le groupe « hr@example.com ».

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

Si vous indiquez le domaine dans la requête, tous les documents partagés avec le domaine sont renvoyés. Le AttributeFilter paramètre suivant renvoie les documents partagés avec le domaine « exemple.com ».

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

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données IBM DB2

Lorsque vous utilisez une source de données IBM DB2, Amazon Kendra vous obtenez des informations sur les utilisateurs et les groupes à partir d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données IBM DB2 présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Jira

Lorsque vous utilisez une source de données Jira, Amazon Kendra elle obtient des informations sur les utilisateurs et les groupes à partir de l'instance Jira.

Les identifiants utilisateur Jira sont mappés comme suit :

  • _user_id—Les identifiants utilisateur existent dans Jira pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants utilisateur dans Jira.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Microsoft Exchange

Lorsque vous utilisez une source de données Microsoft Exchange, Amazon Kendra obtient les informations utilisateur à partir de l'instance Microsoft Exchange.

Les ID utilisateur Microsoft Exchange sont mappés comme suit :

  • _user_id—Les identifiants utilisateur existent dans les autorisations Microsoft Exchange permettant aux utilisateurs d'accéder à certains contenus. Ils sont mappés à partir des noms d'utilisateur en tant qu'ID dans Microsoft Exchange.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources OneDrive de données Microsoft

Amazon Kendra récupère les informations relatives aux utilisateurs et aux groupes auprès de Microsoft OneDrive lorsqu'il indexe les documents du site. Les informations relatives aux utilisateurs et aux groupes proviennent du SharePoint site Microsoft sous-jacent qui les héberge OneDrive.

Lorsque vous utilisez un OneDrive utilisateur ou un groupe pour filtrer les résultats de recherche, calculez l'ID comme suit :

  1. Obtenez le nom du site. Par exemple, https://host.onmicrosoft.com/sites/siteName.

  2. Prenez le hachage MD5 du nom du site. Par exemple, 430a6b90503eef95c89295c8999c7981.

  3. Créez l'adresse e-mail ou l'identifiant de groupe de l'utilisateur en concaténant le hachage MD5 avec une barre verticale (|) et l'identifiant. Par exemple, si le nom d'un groupe est localGroupName « », l'ID du groupe serait :

    "430a6b90503eef95c89295c8999c7981 | localGroupName"

    Note

    Incluez un espace avant et après la barre verticale. La barre verticale est utilisée pour s'identifier localGroupName avec son hachage MD5.

    Pour le nom d'utilisateur « someone@host.onmicrosoft.com », l'ID utilisateur serait le suivant :

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

Envoyez l'ID d'utilisateur ou de groupe Amazon Kendra sous forme d'_group_idattribut _user_id or lorsque vous appelez l'API Query. Par exemple, la AWS CLI commande qui utilise un groupe pour filtrer les résultats de recherche ressemble à ceci :

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

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Microsoft OneDrive v2.0

Une source de données Microsoft OneDrive v2.0 renvoie des informations de section et de page à partir d'entités de liste de contrôle d' OneDrive accès (ACL). Amazon Kendra utilise le domaine du OneDrive locataire pour se connecter à l' OneDrive instance, puis peut filtrer les résultats de recherche en fonction de l'accès des utilisateurs ou des groupes aux sections et aux noms de fichiers.

Pour les objets standard, les _user_id et _group_id sont utilisés comme suit :

  • _user_id— Votre adresse e-mail OneDrive utilisateur Microsoft est mappée _user_id sur le champ.

  • _group_id— L'e-mail de votre OneDrive groupe Microsoft est mappé _group_id sur le champ.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources SharePoint de données Microsoft

Amazon Kendra récupère les informations relatives aux utilisateurs et aux groupes auprès de Microsoft SharePoint lorsqu'il indexe les documents du site. Pour filtrer les résultats de recherche en fonction de l'accès des utilisateurs ou des groupes, fournissez des informations sur les utilisateurs et les groupes lorsque vous appelez l'QueryAPI.

Pour filtrer à l'aide d'un nom d'utilisateur, utilisez son adresse e-mail. Par exemple, johnstiles@example.com.

Lorsque vous utilisez un SharePoint groupe pour filtrer les résultats de recherche, calculez l'ID du groupe comme suit :

Pour les groupes locaux

  1. Obtenez le nom du site. Par exemple, https://host.onmicrosoft.com/sites/siteName.

  2. Prenez le hachage SHA256 du nom du site. Par exemple, 430a6b90503eef95c89295c8999c7981.

  3. Créez l'ID de groupe en concaténant le hachage SHA256 avec une barre verticale (|) et le nom du groupe. Par exemple, si le nom du groupe est localGroupName « », l'ID du groupe serait :

    "430a6b90503eef95c89295c8999c7981 | localGroupName"

    Note

    Incluez un espace avant et après la barre verticale. La barre verticale est utilisée pour s'identifier localGroupName avec son hachage SHA256.

Envoyez l'ID de groupe en Amazon Kendra tant qu'_group_idattribut lorsque vous appelez l'API Query. Par exemple, la AWS CLI commande ressemble à ceci :

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

Pour les groupes AD

  1. Utilisez l'ID du groupe AD pour configurer le filtrage des résultats de recherche.

Envoyez l'ID de groupe en Amazon Kendra tant qu'_group_idattribut lorsque vous appelez l'API Query. Par exemple, la AWS CLI commande ressemble à ceci :

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

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Microsoft SQL Server

Lorsque vous utilisez une source de données Microsoft SQL Server, Amazon Kendra vous obtenez des informations sur les utilisateurs et les groupes à partir d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Microsoft SQL Server présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Microsoft Teams

Amazon Kendra récupère les informations utilisateur de Microsoft Teams lorsqu'il indexe les documents. Les informations utilisateur sont extraites de l'instance Microsoft Teams sous-jacente.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Microsoft Yammer

Amazon Kendra récupère les informations utilisateur de Microsoft Yammer lorsqu'il indexe les documents. Les informations relatives à l'utilisateur et au groupe sont extraites de l'instance Microsoft Yammer sous-jacente.

Les ID utilisateur Microsoft Yammer sont mappés comme suit :

  • _email_id— L'adresse e-mail Microsoft mappée au _user_id champ.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données MySQL

Lorsque vous utilisez une source de données MySQL, les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données MySQL présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Oracle Database

Lorsque vous utilisez une source de données Oracle Database, les informations relatives aux utilisateurs et aux groupes sont Amazon Kendra extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données Oracle Database présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données PostgreSQL

Lorsque vous utilisez une source de données PostgreSQL Amazon Kendra , les informations relatives aux utilisateurs et aux groupes sont extraites d'une colonne de la table source. Vous spécifiez cette colonne dans la console ou en utilisant l'TemplateConfigurationobjet dans le cadre de l'CreateDataSourceAPI.

Une source de données de base de données PostgreSQL présente les limites suivantes :

  • Vous pouvez uniquement spécifier une liste d'autorisations pour une source de données de base de données. Vous ne pouvez pas spécifier de liste de refus.

  • Vous ne pouvez spécifier que des groupes. Vous ne pouvez pas spécifier d'utilisateurs individuels pour la liste d'autorisation.

  • La colonne de base de données doit être une chaîne contenant une liste de groupes délimitée par des points-virgules.

Filtrage du contexte utilisateur pour les sources de données Quip

Lorsque vous utilisez une source de données Quip, Amazon Kendra elle obtient les informations utilisateur de l'instance Quip.

Les identifiants utilisateur Quip sont mappés comme suit :

  • _user_id—Les identifiants utilisateur existent dans Quip pour les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants dans Quip.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Salesforce

Une source de données Salesforce renvoie des informations sur les utilisateurs et les groupes à partir des entités de la liste de contrôle d'accès (ACL) Salesforce. Vous pouvez appliquer le filtrage du contexte utilisateur aux objets standard et aux flux de discussion Salesforce. Le filtrage du contexte utilisateur n'est pas disponible pour les articles de connaissances de Salesforce.

Si vous associez un champ Salesforce aux champs du titre et du corps du document Amazon Kendra, Amazon Kendra utilisera les données du titre et des champs du corps du document dans les réponses de recherche.

Pour les objets standard, les _user_id et _group_ids sont utilisés comme suit :

  • _user_id: le nom d'utilisateur de l'utilisateur Salesforce.

  • _group_ids—

    • Nom de la Salesforce Profile

    • Nom de la Salesforce Group

    • Nom de la Salesforce UserRole

    • Nom de la Salesforce PermissionSet

Pour les fils de discussion, les _user_id et _group_ids sont utilisés comme suit :

  • _user_id: le nom d'utilisateur de l'utilisateur Salesforce. Disponible uniquement si l'article est publié dans le fil de l'utilisateur.

  • _group_ids—Les identifiants de groupe sont utilisés comme suit. Disponible uniquement si l'élément du fil est publié dans un groupe de discussion ou de collaboration.

    • Le nom du chatteur ou du groupe de collaboration.

    • Si le groupe est public,PUBLIC:ALL.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources ServiceNow de données

Le filtrage du contexte utilisateur pour n' ServiceNow est pris en charge que pour l' TemplateConfiguration API et le ServiceNow Connector v2.0. ServiceNowConfigurationL'API et le ServiceNow connecteur v1.0 ne prennent pas en charge le filtrage du contexte utilisateur.

Lorsque vous utilisez une source de ServiceNow données, Amazon Kendra elle obtient les informations relatives aux utilisateurs et aux groupes à partir de l' ServiceNow instance.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans ServiceNow les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms de rôles de sys_ids in ServiceNow.

  • _user_id—Les identifiants utilisateur existent dans ServiceNow les fichiers pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs au fur et à mesure que les identifiants entrent. ServiceNow

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Slack

Lorsque vous utilisez une source de données Slack, Amazon Kendra elle obtient les informations utilisateur de l'instance Slack.

Les identifiants utilisateur Slack sont mappés comme suit :

  • _user_id—Les identifiants utilisateur existent dans Slack pour les messages et les chaînes pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs sous forme d'identifiants dans Slack.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.

Filtrage du contexte utilisateur pour les sources de données Zendesk

Lorsque vous utilisez une source de données Zendesk, vous obtenez les informations Amazon Kendra de l'utilisateur et du groupe à partir de l'instance Zendesk.

Les identifiants de groupe et d'utilisateur sont mappés comme suit :

  • _group_ids—Les identifiants de groupe existent dans les tickets et les articles Zendesk pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des noms des groupes dans Zendesk.

  • _user_id—Les identifiants de groupe existent dans les tickets et les articles Zendesk pour lesquels des autorisations d'accès sont définies. Ils sont mappés à partir des e-mails des utilisateurs en tant qu'identifiants dans Zendesk.

Vous pouvez ajouter jusqu'à 200 entrées dans le AccessControlList champ.