View a markdown version of this page

Document-level contrôles d'accès - Amazon Bedrock
Comment ça marcheQu'est-ce qui est crawléActiver la sensibilisation à l'ACLReal-time vérification d'accèsVérification de votre configurationRésolution des problèmes

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.

Document-level contrôles d'accès

La connaissance de l'ACL n'est pas une autorisation

La base de connaissances gérée Bedrock fournit un ACL-aware filtrage et non une limite de sécurité. La base de connaissances gérée Bedrock n'authentifie pas les utilisateurs finaux. Votre application est chargée d'authentifier les utilisateurs et de transmettre le contexte d'identité vérifié. Étant donné que Bedrock Managed Knowledge Base ne peut pas vérifier l'authenticité du contexte utilisateur que vous fournissez, cette fonctionnalité filtre les résultats en fonction de l'identité que vous fournissez mais ne constitue pas une véritable autorisation. Vous ne devez pas vous fier à cette fonctionnalité comme seul mécanisme de contrôle d'accès sans authentification en amont.

Les sources de données Confluence prennent en charge en option le contrôle d'accès au niveau du document. Lorsque cette option est activée, Bedrock Managed Knowledge Base synchronise les listes de contrôle d'accès (ACL) de Confluence lors de chaque analyse et vérifie les autorisations de chaque utilisateur au moment de la requête, afin que les utilisateurs ne voient que les résultats des documents auxquels ils sont autorisés à accéder dans Confluence. Pour une vue d'ensemble de la prise en compte des ACL sur tous les connecteurs, voirSensibilisation aux listes de contrôle d'accès.

Comment ça marche

Lorsqu'un utilisateur interroge une base de connaissances qui utilise une source de données ACL-enabled Confluence, Bedrock Managed Knowledge Base applique les contrôles d'accès en deux étapes :

  • Pre-retrieval filtrage — Bedrock Managed Knowledge Base applique les listes de contrôle d'accès synchronisées depuis Confluence lors du dernier crawl, renvoyant uniquement les documents candidats auxquels l'utilisateur (ou ses groupes) est autorisé à accéder.

  • Real-time vérification — Bedrock Managed Knowledge Base vérifie les documents candidats en temps réel en vérifiant l'accès actuel de l'utilisateur demandeur à Confluence. Seuls les documents auxquels l'utilisateur est actuellement autorisé à accéder sont inclus dans la réponse.

Cette approche en deux étapes fournit un contrôle d'accès au niveau du document qui reste actuel même lorsque les autorisations Confluence changent entre les synchronisations.

Qu'est-ce qui est crawlé

Lorsque les ACL sont activées, la base de connaissances gérée de Bedrock explore les structures d'autorisation suivantes depuis Confluence :

  • Espaces : les autorisations d'espace s'appliquent par défaut à tous les documents de l'espace.

  • Pages — Les pages peuvent être limitées à des utilisateurs et à des groupes spécifiques. Les pages imbriquées héritent des restrictions de la page parent.

  • Blogs — Les articles de blog peuvent être limités à des utilisateurs et à des groupes spécifiques.

  • Pièces jointes — Les fichiers joints aux pages ou aux articles de blog héritent des contrôles d'accès de leur document parent.

Activer la sensibilisation à l'ACL

Pour activer la prise en compte des ACL pour une source de données Confluence, définissez le type aclEnabled d'authentification sur true in the connectorParameters et utilisez le type d'BASICauthentification. Le secret doit inclure les informations d'identification de l'administrateur de l'organisation Atlassian en plus de l'e-mail standard et du jeton d'API. Ces informations d'identification d'administrateur sont requises pour l'analyse des identités.

Important

La configuration de l'ACL est permanente. Vous ne pouvez pas activer les ACL sur une source de données créée sans support ACL, et vous ne pouvez pas désactiver les ACL une fois activées.

Outre le code standard username password (jeton API) et hostUrl les champs, le AWS Secrets Manager secret doit inclure les champs d'administration de l'organisation suivants. Pour obtenir des instructions détaillées permettant d'obtenir ces valeurs, consultezConfigurer l'authentification de base pour Confluence.

  • adminApiKey— Une clé d'API d'organisation Atlassian avec les champs d'application read:directories:admin etread:workspaces:admin.

  • organizationId— L'UUID de votre organisation Atlassian.

  • directoryId— L'UUID du répertoire des utilisateurs de votre espace de travail Confluence.

Note

Le type d'OAUTH2authentification n'est pas pris en charge pour les sources de données ACL-enabled Confluence. Vous devez utiliser les informations BASIC d'administration de l'organisation Atlassian dans le secret.

Real-time vérification d'accès

Bedrock Managed Knowledge Base vérifie chaque document candidat par rapport à Confluence au moment de la requête, entièrement côté serveur, à l'aide du jeton Atlassian Admin API configuré dans le secret : il n'y a pas de connexion de l'utilisateur final. Le jeton d'administration vérifie les restrictions d'espace, de page et de blog actuelles de l'utilisateur demandeur, afin que les modifications d'accès apportées depuis le dernier crawl soient respectées.

Vérification de votre configuration

Vous pouvez valider vos informations d'identification indépendamment d'une demande de récupération. Effectuez chacune des vérifications suivantes :

  1. Accès au contenu Confluence (crawl) :

    • À l'aide du jeton d'API username et (password) du secret, appelez l'API REST de Confluence (par exemple, des espaces de liste) et confirmez qu'elle renvoie le protocole HTTP 200.

  2. API Atlassian Admin (analyse des identités et vérification en temps réel) :

    • Confirmez adminApiKey qu'il possède les read:workspaces:admin portées read:directories:admin et.

    • À l'aide deadminApiKey, appelez l'API du répertoire d'administration Atlassian pour vous organizationId directoryId et confirmez qu'elle renvoie les utilisateurs et les groupes de votre organisation.

Résolution des problèmes

Note

Les erreurs de configuration de l'ACL ne produisent pas d'erreurs explicites lors de la récupération. La récupération échoue à la fermeture : les documents concernés sont omis en silence, de sorte qu'une requête renvoie moins de résultats, voire aucun, plutôt qu'une erreur. Utilisez les contrôles de vérification ci-dessus pour diagnostiquer ces problèmes.

ACL-enabled Symptômes, causes et solutions de la confluence
Symptôme Cause probable Corriger
Retrieve ne renvoie aucun résultat, mais l'utilisateur a accès à Confluence. La clé de l'API Atlassian Admin n'a pas de portée ou leorganizationId/directoryIdest incorrect. Les restrictions relatives aux utilisateurs et aux groupes ne peuvent donc pas être résolues. Confirmez que read:directories:admin les adminApiKey a etread:workspaces:admin, organizationId et cela directoryId sont corrects.
L'exploration ou la synchronisation échouent. Le jeton d'API username or (password) n'est pas valide. Vérifiez le BASIC nom d'utilisateur et le jeton d'API dans le secret.
Tous les utilisateurs sont refusés après avoir travaillé auparavant. Le jeton d'API ou la clé d'API d'administration a expiré ou a été révoqué. Faites pivoter les informations d'identification concernées dans le secret.