View a markdown version of this page

Document-level contrôles d'accès - Amazon Bedrock
Comment ça marcheQu'est-ce qui est rampéActiver la sensibilisation à l'ACLReal-time vérification de l'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 sensibilisation à l'ACL n'est pas une autorisation

La base de connaissances gérée de Bedrock fournit un ACL-aware filtrage, et non une limite de sécurité. La base de connaissances gérée de 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 la base de connaissances gérée de Bedrock 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 éventuellement en charge le contrôle d'accès au niveau du document. Lorsque cette option est activée, la base de connaissances gérée de Bedrock synchronise les listes de contrôle d'accès (ACL) de Confluence à chaque analyse et vérifie les autorisations de chaque utilisateur au moment de la requête, de sorte 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, consultezActivation de la sensibilisation 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  : la base de connaissances gérée de Bedrock applique les listes de contrôle d'accès qui ont été synchronisées depuis Confluence lors de la dernière analyse, en renvoyant uniquement les documents candidats auxquels l'utilisateur (ou ses groupes) sont autorisés à accéder.

  • Real-time vérification — La base de connaissances gérée de Bedrock 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 à jour même lorsque les autorisations Confluence changent entre les synchronisations.

Qu'est-ce qui est rampé

Lorsque les ACL sont activées, Bedrock Managed Knowledge Base explore les structures d'autorisation suivantes depuis Confluence :

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

  • Pages — Les pages peuvent être réservé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 réservés à des utilisateurs et à des groupes spécifiques.

  • Pièces jointes  : les fichiers joints à des pages ou à des 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 aclEnabled connectorParameters et utilisez le type d'BASICauthentification. true 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 qu'elles sont activées.

Outre les champs standard username password (jeton d'API) et, le AWS Secrets Manager secret doit inclure les hostUrl 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 étendues read:directories:admin etread:workspaces:admin.

  • organizationId— L'UUID de votre organisation Atlassian.

  • directoryId— L'UUID de l'annuaire 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'identification d'administrateur de l'organisation Atlassian dans le secret.

Real-time vérification de l'accès

La base de connaissances gérée de Bedrock vérifie chaque document candidat par rapport à Confluence au moment de la requête, entièrement côté serveur, à l'aide du jeton d'API Atlassian Admin configuré dans le secret. Il n'y a pas de connexion utilisateur final. Le jeton d'administration vérifie les restrictions d'espace, de page et de blog actuelles de l'utilisateur effectuant la requête, 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) contenu dans le secret, appelez l'API REST 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) :

    • Vérifiez qu'adminApiKeyils ont les read:workspaces:admin portées read:directories:admin et.

    • À l'aide duadminApiKey, appelez l'API d'annuaire 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 des ACL ne produisent pas d'erreurs explicites lors de la récupération. La récupération échoue : les documents concernés sont omis en silence, de sorte qu'une requête renvoie moins de résultats, voire aucun résultat, au lieu d'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 renvoie 0 résultat, mais l'utilisateur a accès à Confluence. La clé d'API Atlassian Admin n'a pas de champs d'application, ou leorganizationId/directoryIdest erroné. Les restrictions relatives aux utilisateurs et aux groupes ne peuvent donc pas être résolues. Vérifiez que les adminApiKey read:directories:admin caractères ont etread:workspaces:admin, organizationId et que directoryId sont corrects.
L'exploration ou la synchronisation échouent. Le jeton username ou API (password) n'est pas valide. Vérifiez le BASIC nom d'utilisateur et le jeton d'API contenus dans le secret.
Tous les utilisateurs sont refusés après avoir travaillé précédemment. 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.